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THESIS DISCLAIMER 

The reader is cautioned that computer programs developed in this research may not 
have been exercised for all cases of interest. While every effort has been made, within 
the time available, to ensure that the programs are free of computational and logic er- 
rors, they cannot be considered validated. Any application of these programs without 
additional verification is at the risk of the user. 
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I. INTRODUCTION 



A. VHSIC HARDWARE DESCRIPTION LANGUAGE (VHDL) 

While system standards such as the Unix and the X Window System continue to be 
refined and redefined, significant application-level standards are emerging. On one hand, 
there is explosive growth of electronic computer-aided engineering (CAE) and 
computer-aided design (CAD). On the other hand, because of the lack of a standard, 
numerous dissimilar and incompatible CAE/CAD databases have proliferated. 

New circuit designs inevitably will adopt part of old designs which were proven to 
be applicable even with a device technology break-through. Because of the large number 
of vendor-specific CAE CAD formats, tools, and languages, the portability of designs 
are difficult, if not impossible. Consequently, designers tend to redevelop their designs 
in the new working environment rather than port the existing designs from another in- 
compatible working environment. Different formats and tools continue to grow. It 
causes system design to be even more inefficient. The need for an industry standard is 
apparent. 

When the Department of Defense launched the Very High Speed Integrated Circuit 
(VHSIC) project, it was confronted with the problems mentioned above. Furthermore, 
since most of the government systems tend to have a long service life, the last system 
on a given program might well be delivered fifteen years after the first production ship- 
ment. Both would be expected to remain in operation for at least ten years from that 
point in time. Technology, on the other hand, is irrevocably non-static. Technology 
used in the first delivery would be something quite different from those of twenty-five 
years later. Yet. the operating systems and their maintenance require compatible re- 
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placement of components. Standardization, if it could accomplish this, could also assist 
in the procurements from second sources [Ref. lj. 

In the early stage of the VHS1C program, an idea arose that these problems might 
be resolved through the development of a standard hardware description language 
(HDL). A program was launched in August of 1983 for the development of a VHSIC 
Hardware Description Language (VHDL) [Ref. 1]. 

The goal of the program was to develop a language which could simultaneously 
function as a design automation tool interface and as a mechanism for documenting the 
design of a transportable electronic system and its components. 

In August 1985, version 7.2 of the language was released by the Department of 
Defense. After the release of version 7.2. the IEEE sponsored the standardization. The 
goal was the development of an improved standard of the language. The review process 
was completed by May 1987 and the language reference manual (LRM) was released for 
industrial review. In December 1987 VHDL was accepted as IEEE-STD-1076-1987. 

Initially, the VHDL was geared toward system-level design and documentation. 
However, after the design of the language has received inputs from many individuals in 
the computer industry, the VHDL offers not only behavioral constructs [Ref. 2] but also 
register transfer-level (RTL) and structural (i.e., gate level) constructs. The user thus can 
describe a circuit at the register and the gate levels as well as the behavioral level. 

B. ERASABLE PROGRAMMABLE LOGIC DEVICE (EPLD) 

To achieve improved system performance in the marketplace, more and more man- 
ufacturers have sought higher levels of integration (functional density) for the electronic 
components in the design. This led to various forms of custom chips. Yet, the custom 

chips design has the following problems: 

1. Development lead times are relatively long. 

2. Design cost are significant. 



3. Inventory is dedicated to a specific application which is expensive. This prohibits 
adequate second sources. 

4. Design changes in midstream are not allowed due to lead time and inventory con- 
straints. 

The concept of the erasable programmable logic device (EPLD) is to provide the 
user the benefits of large scale integration circuit without the drawbacks of full custom 
chips. The benefits of such parts include off-the-shelf availability, minimal design costs, 
multiple sourcing from distributors, and flexible interchangeable inventor} 7 . 

The EPLD basically consists of two parts. The first part is the conventional pro- 
grammable array logic (PAL) structure. The second part is a user-configurable I/O 
control architecture. Inside the I/O control architecture there are signal path, select 
switches, and flip-flops. 

With improved techniques, the speed and functional density of EPLD's are getting 
faster and higher. This makes the EPDL even more attractive. It is believed that more 
special purpose logic designs will use EPLD in place of the custom chips. 

C. EPLD MODELING 

In this study the VHDL language is used to model two EPLD chips, to find out 
what kind of problems will be encountered when modeling this type of chips, and to 
propose the VHDL solutions to these problems. 

The best way to describe the EPLD is at a register transfer level. In this study the 
register transfer level models are used to simulate both the EP310 and the EP1800. 
These devices are EPLD with approximately 300 and 2100 gates, respectively. 

A general introduction of the VHDL language and its working environment is the 
main subjects of Chapter II. In Chapter III the structure of a small scale EPLD, EP310. 
is first introduced. It is followed by a general introduction of the EPLD's design envi- 
ronment. Then, the specific problems encountered in modeling the EP310 chip are dis- 
cussed. Chapter IV introduces the modeling of a large scale EPLD, EP1800. The 
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advantage and disadvantage of using the VHDL language in modeling a digital circuit 
design is discussed in Chapter V. At the end, Appendix A contains the VHDL source 
codes for the EP310 and the EP1800 models. Appendix B contains two simulation ap- 
plication VHDL sources files and their results. Appendix C contains an example of the 
signal select file used in the VHDL supporting environment and a signal map example 
which is produced by the VHDL supporting environment. Appendix D contains the 
procedures of constructing the EP310 model and the EP1800 model in the VHDL 1076 
standard supporting environment installed at the Naval Postgraduate School. 
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II. VHDL FEATURE AND ENVIRONMENT 



A. BASIC FEATURES OF VHDL 

This chapter constitutes a brief introduction of the VHDL. The advanced features 
of the VHDL and corresponding examples related to the EPROM modeling will be in- 
troduced later when they are encountered. 

1. DESIGN ENTITIES 

In VHDL, a given section of a logic circuit is represented as a design entity. The 
logic circuit represented can be as complicated as an entire system or as simple as an 
AND gate. A design entity is defined by an entity declaration together with one or more 
corresponding architecture bodies as shown in Figure 1. 

An entity declaration basically defines the interface between a given design en- 
tity and the environment in which it is used. The actual relationship between these in- 
puts and outputs is specified in the architectural body. This body can specify the 
behavior of the entity directly such as a primitive body. The architectural body can also 
be structurally decomposed into simpler components. As shown in Figure’ 1, "Architec- 
ture A" is decomposed into smaller components. Each one of the components is an 
entity itself, and were binded to the "Architecture A" by "configuration specifications". 

Illustrated below is an example that shows the basic features of an entity dec- 
laration. 

entity FULL_ADDER is 

generic(sum_delay ,carry_delay: TIME: =25ns); 
port(x,y,cin: in BIT;z,cout: out BIT); 
end FULL_ADDER: 
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Figure 1. Scheme for various architectural bodies in one entity 
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The entity name of the above example is "FL'LL_ADDER" and its ports are "x", "y", 
"cin", "z", and "cout". Each port has an associated mode, which identifies input, output, 
and an associated type. In this case, all the signals have the same signal type, i.e., BIT. 

The terms port and generic in the entity declaration above serve as the interface 
of the module. Port is used to pass the declared signals from external entity into the 
module. Generic is used to pass the parameters from the external entity into the module. 
With generic as an interface, it is possible to reuse a design entity whenever practical. 
For example, generic can be used to pass a faster delay parameter to the module to 
simulate a faster device. If the variable of a generic appear in a conditional signal as- 
signment statement, then the behavior of the design entity may be changed by changing 
the value of that generic variable. 

Given the entity interface it is also necessary to specify what the 
"FULL_ADDER" does in an architectural body. An example is shown below: 

architectural Data_Flow of FULL_ADDER is 
begin 

z<=x xor y xor cin after 20ns; 

cout<=(x and y)or(x and cin) or(y and cin) after 25ns; 
end Data_Flow; 

The structural body used in the above example is a behavioral description not 
involving the actual physical device. In most of the cases, the behavioral description 
model is the first step in building a real system. 
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Figure 2. Tull adder gate structure 

As mentioned before, a single entity may have several architectures corre- 
sponding to different ways of realizing the entity. Figure 2 is a physical structure of the 
'TljLL_ADDER", and Figure 3 is the structural realization of it in VIIDL. 
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architectural STRUCTURAL of FULL_ADDER is 
begin 

component and_gate 

generic (delay: TIME := 5ns); 
port (a,b:in BIT;c out BIT); 
end component; 
component xor gate 

generic (delay: TIME := 5ns); 
port (a,b:in BIT;c out BIT); 
end component: 
component or_gate 

generic (delay: TIME := 5ns); 
port (a.b:in BIT;c out BIT); 
end component; 
signal loci, loc2, loc3: BIT; 
begin 

X l:\or_gate port map: (x.y.locl); 

X2:xor_gate port map: (loc Lein, sum); 
Al:and_gate port map: (cin,locl,loc2); 
A2:and_gate port map: (x,y.loc3); 

Ol:or_sate port map (loc2,loc3, cout); 
end STRUCTURAL; 



Figure 3. Full_Adder VHDL structural description 



entity and_gate is 

generic (delay: TIME : = 5ns): 
port (a.b: in BIT; c: out BIT); 
end 

architecture BEHAVIOR of and_gate is 
begin 

c < = a and b; 
end BEHAVIOR; 



Figure 4. Description of and_gate component 
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entity or_gate is 

generic (delay: TIME : = 5ns); 
port (a,b: in BIT; c: out BIT); 
end 

architecture BEHAVIOR of or_gate is 
begin 

c < = a or b; 
end BEHAVIOR; 



Figure 5. Description of or_gate component 



entity xor_gate is 

generic (delay: TIME : = 5ns); 
port (a,b: in BIT; c: out BIT); 
end 

architecture BEHAVIOR of xor_gate is 
begin 

c < = a xor b; 
end BEHAVIOR; 



Figure 6. Description of xor_gate component 



Three components, xor_gate, and_gate, and or_gate, are declared in the decla- 
ration section of the architecture "STRUCTURAL" in Figure 3. The port specification 
used in the components of the "FL’LLADDER" indicates that there are two input sig- 
nal "a", "b", and an output signal "c". The entity of these components have the identical 
port specifications as the "FULL_ADDER" dose, (see Figure 4, Figure 5, and 
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Figure 6). Three signals loci, loc2, and loc3 are also declared in the "FULL_ADDER". 
These declared signals are local signals, which are visible only inside the 
"FULL_ADDER" entity. 

In the "FULL_ADDER" entity, five components are instantiated after the key 
word begin; that is, five specific instances of general component entities are created. In 
each instantiation, there is a unique label associated with it (i.e., XI, X2, Al, A2, and 
Ol ) as well as a port map. The generic map is optional. If the generic map is not stated 
in the instantiation, the assigned default value will be used. In the above case, since all 
the component instantiations does not state their generic map, the generics of the com- 
ponents will use their default value, i.e., five nanosecond delay. 

The port map creates an association between the inputs/outputs of the compo- 
nent declaration and the signals in the instantiated components. In the 
"FULL_ADDER" case the association is "by position". Named association can also be 
used, which looks like the following: 

Al: and_gate port map (c=>loc2, a=>cin, b=>cin); 

2. CONCURRENT STATEMENTS 

Some of the most important characteristics of the concurrent statements are 
described in this section. Concurrent statements are used to define interconnected 
blocks and processes that jointly describe the overall behavior or structure of a design 
entity. Concurrent statements are executed asynchronously with respect to each other. 
a. BLOCK S TA TEMENT 

The basic concurrent statement in VHDL is the block statement. The block 
consists of the declaration section as well as an executable section. The executable sec- 
tion can have all possible concurrent statements, which may include other block state- 
ments. The architectural body of the entity itself is basically a block. Consider the 
example shown in Figure 7. Here, the architectural body "BLOCK_STRUCTURE" can 



11 



be seen as an outer block. The block "A" under the "BLOCK_STRUCTURE" is its in- 
ner block. In general, any number of nestings of blocks are possible. Note that in Fig- 
ure 7 the text following the symbol are comments in VHDL and will not be 
executed. 



architecture BLOCK_STRL'CTURE of FULL_ADDER is 
— Outer Block Declaration Section 
signal loci : BIT; 
begin 

- Outer Block Executable Section 
loci < = x xor y after delay; 
sum < = loci xor cin after delay; 

Arblock 

- Inner Block A Declaration Section 

signal lacl,loc2,loc3,loc4 : BIT; 
begin 

— Inner Block A Executable Section 
loci < = x and y after delay; 
loc2 < = y and cin after delay; 
loc3 < = loci or loc2 after delay; 
loc4 < = loc3 or loc4 after delay; 
cout < = loc3 or loc4 after delay; 
end block A: 

end BLOCK_STRUCTL RE; 



Figure 7. Example of nested blocks 



In VHDL, the block statement contains an optional guard expression. If 
there is an expression immediately following the key word block, then an implicit signal 
called guard with a type BOOLEAN will be created. The value of guard is dependent 
on the condition of the expression that follows the block. When a "guard condition" 
becomes TREE, it can enable certain types of statements inside the block. By using a 
"guarded block" it is possible to model the operation of a synchronous circuit. 
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Figure S. D latch block diagram 



entitv D_Latch is 

port(CLK.CLR,D:in BIT; Q,Q_not:out BIT); 
end D Latch; 

architecture GUARDED_CLOCK of D_Latch is 
begin 

block(CLK = T or CLR= T) 
signal S: BIT; 
begin 

S < = guarded '0' nhen CLR= '1' else 
D; 

Q < = S after 10ns; 

Q_not < = not s after 10ns; 
end block: 

end GUARDED_BLOCK; 



Figure 9. Example of D latch using guarded block 



A "guarded block" example is given by modeling the D latch as shown in 
Figure 8. This D latch will reflect the value of the input signal "d" when the clock 
(CLK) is high, i.e., equal to '1'. The latch also contains an asynchronous clear (CLR) 
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input. When CLR = 1, the latch is reset. The asynchronous clear overrides the clock. 
The corresponding latch model is shown in Figure 9. The block header expression 
"(CLK = T' or CLR=T')" define the value of the implicit guard. The statements con- 
tains the key word guarded will not be executed unless the value of guard is TRUE. In 
the D latch case, if the guard is FALSE, the local signal S will remain the same value. 
If the guard is TRUE and the CLR is a T, then S will be assigned to 'O'; otherwise S 
will follow the input signal D. Note that the D latch illustrated above is a level-sensitive 
device. It will be shown in Chapter III that the guard is not restricted to level-sensitive. 
Edge-sensitive guard is available as well. 
b. PROCESS S TA TEMENT 

Another major modeling element in VHDL is the process., A process state- 
ment defines an independent sequential process. The process can represent the behavior 
of some portion of a design. An example is shown in Figure 10. Note that the process 
begin with the key word process(line). The parameter inside the parenthesis is called the 
sensitivity list. Whenever the signal inside the sensitivity list change, the process is ac- 
tivated and the statements within the process are executed. 

3. DATA TYPES 

The type is an important feature of VHDL. The VHDL is strongly typed, which 
means that inadvertent mixing of types in an operation will be flagged as an error. The 
strong typing features are very helpful for capturing the designer's intent; they also help 
to check the design data-flow correctness. 

A type is characterized by a set of values and a set of operations. A subtype is 
a subset of the values of a type. The set of operations defined for a subtype include the 
operations defined for the parent type; however, the assignment operation to an object 
having a given subtype only assigns values that belong to the subtype. 



14 



process (line) 
begin 

pulse < = T after 5ns, '0' after 15ns; 
end process; 



line: 



pulse: 



TIME(ns) 



I 

1 

1 




1 
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1 
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I 
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1 
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t 



t +10 +20 +30 +40 



+50 +60 



Figure 10. Process statement: (Pulse Converter) 



In the V1IDL the set of all integers are predefined as type INTEGER, and all 
positive integers are predefined as subtype POSITIVE in the following declaration 



subtype POSITIVE is INTEGER range 1 to INTEGER’ HIGH; 



Where the attribute 'HIGH will yield the upper bound value of the INTEGER. Here, 
with the key word range the subtype POSITIVE will have the same upper bound value 
as the INTEGER has. According to the subtype operation rule mentioned above, the 
subtraction operation implied for INTEGER, may not be used in subtype POSITIVE, 
because the subtraction of two positive numbers may produce a negative value. 
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The "YHDL Language Reference Manual" gives a useful data type classification 
scheme which is illustrated in Figure 11. Data types are classified as scalar (one- 
dimensional) or composite (multidimensional). The enumeration type is the most fre- 
quently used scalar types. For example, the predefined type BIT is an enumeration type, 
which is defined as follows: 

type BIT is ( ’ 0 ' , ' l'); 

Xumeric types are either INTEGER or REAL. The REAL type can be very 
useful in modeling an anlog-to-digital interface or a signal processing algorithm. Some 
type declaration examples are illustrated below: 
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type INDEX is range 0 to 9; --integer type, 
type VOLTAGE is range 0.0 to 10.0; --real type. 

Each of the type declared in above example has a range. The base type (i.e., either IN- 
TEGER or REAL) is implied by the values in the range. 

The VHDL also provides the physical type, which is used to represent some 
physical quantities (such as, time, voltage, and capacity). TIME is a predefined physical 
type in VHDL, and its declaration is shown below: 



type TIME is 


range implementation jdef ined 


units 








fs; 






-- femtosecond 


ps 


- 


lOOOfs; 


-- picosecond 


ns 


= 


lOOOps; 


-- nanosecond 


us 


= 


1000ns; 


-- microsecond 


ms 


= 


lOOOus; 


-- millisecond 


sec 


= 


1000ms; 


-- second 


min 


= 


60sec; 


-- minute 


hr 


= 


60min; 


-- hour 


end units; 









Note that the base unit in TIME is femtoseconds (fs). Both the range and the base unit 
are user selectable. But, the upper bound of the range cannot exceed the host machine 
limit. With the range from 0 to 1E20, the TIME can represent up to 27.7 hours (100,000 
second). 

The Composite types are either array types or record types. Below is an array 
type declaration example: 

type BYTE is array(0 to 7) of BIT; 
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As declared above, BYTE is an array type of eight array elements. BIT is the 
base type of these array elements. Index range of the BYTE is constrained and is from 
"0 to 7". Another example with unconstrained index range is shown below: 

type BIT_VECTOR is array( NATURAL range <>) of BIT; 

The expression "NATURAL" in BIT_VECTOR above means that the index has a 
subtype of natural number, i.e., non negative number. The symbol " < > " following the 
key word range stands for an undefined range. The user must specify this range when 
it is employed. For example, BIT_VECTOR(0 to 7) for ascending range, or 
BIT_VECTOR(7 downto 0) for descending range. 

As the name implies, a record type is a composite type consisting of a number 
of fields. For example, type DATE could be defined as a record type as follows: 

type DATE is 
record 

DAY : INTEGER range 1 to 31; 

MONTH : MONTH_NAME; 

YEAR : INTEGER range 0 to 3000; 
end record; 

The type MONTH_NAME would be an enumeration type consisting of the names of 
the months. 

As mentioned before, the variable in VHDL are strongly typed, and this means 
that the objects with different types cannot be involved in the expression directly. An 
example is illustrated as follows: 
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-- declaration part 

signal A : BYTE := "00001111"; 

signal B : BIT_VECTOR(0 to 7) := "llllOOOO"; 

signal C : BYTE; 

-- expression part 

C <= A and B; -- this expression will NOT be accepted by VHDL 

Although the A and the B all have eight bits, because they are different types, the VHDL 
will not accept the expression shown in the above example. Note that in the declaration 
part, the signal A is assigned with an initial value via the symbol ": = " immediately fol- 
lowing the type. 

4. CLASS OF OBJECTS 

In VHDL there are three classes of objects: constant, signals, and variables. 

a. Constants 

A constant is an object whose value may not be changed. Some examples 
of constant declarations are: 

constant PI : REAL : =3. 1416; 

constant MESSAGE : STRING( 1 to 13) := "demonstration"; 

Note that each constant declaration must includes the name, the type, and the value of 
the constant. 

b. Variables 

Variables are objects whose values can be changed. When a variable is 
created by a declaration, a container for the object is created along with it. Variables 
are changed by executing a variable assignment statement; for example, 

A := B + C; 
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Variable assignment statements have no time dimension associated with them, i.e., their 
effect is felt immediately. Thus, variables have no direct hardware correspondence. But, 
they are useful in algorithmic representations. Some examples of the variable declara- 
tions are: 

variable FLAG : BOOLEAN := TRUE; 
variable COUNT : INTEGER := 0; 

The variable declarations specify the name, type, and optionally an initialization value 
for the variable. Variables used in a process block are considered to be static, that is, the 
value of the variable is maintained by the simulator until it is changed by a variable as- 
signment statement. 

c. Signals 

Signals are objects whose values may be changed, and the execution has a 
time dimension. Signal values are changed by signal assignment statements. The signal 
assignment statements are evaluated whenever one of the right hand elements of the 
statements changed its value. An example is shown in Figure 12. Note that the signal 
assignment statement uses the " < = " symbol in order to differentiate it from the vari- 
able assignment statement. The "after 10ns" in Figure 12 means that the "local" will take 
on its new value 10 ns later from the present simulation time. If the signal assignment 
statement has no after clause, then it is equivalent to "after 0ns". 

All the signal assignment statements in the same process level are concur- 
rently executed in the same simulation cycle. Consequently, the positions of the signal 
assignment statements in the same process level are irrelevant. Thus, the signal assign- 
ment statements in Figure 12 can also be rewritten as 

d <= local and c; 

local <= a and b after 10 ns; 
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One of the difference between variables and signals is that signals can have 
multiple queuing containers called drivers. The value of the signal is a function of all the 
related drivers. An example related to multiple drivers is shown in Figure 13. In the 
figure two signal assignment statements A and B assign values to the same signal X. 
For each signal assignment, a driver is created to hold the result of that assignment. In 
this example, drivers are labeled Dax and Dbx. The value of the signal X is determined 
by a resolution function F in this example. The resolution function F is user defined. It 
is activated whenever the drivers receive new values. The value of the signal is updated 
to the new value that coming from the resolution function. In Chapter III, the use of 
a resolution function to model the EP310 will be shown. 
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Signal assignment A 



X 

Signal 




Figure 13. Multiple signal drivers and resolution function: [From Ref. 3] 

5. ATTRIBUTES 

An attribute defines and evaluates some characteristics of a named object. Some 
attributes are predefined and are related to types, ranges, values, signals, or functions 
[Ref 4: pp.4-14,15]. Signal attributes are particularly important in modeling. Some 

predefined signal attributes are shown in the following examples: 

1. S'EVENT returns a BOOLEAN value. If an event has occurred on S during the 
current simulation cvcle the returned value is TRUE; otherwise, it returns the value 
FALSE. 

2. S'STABLE(T) is of type BOOLEAN. It is TRUE if S has been stable for the last 
T time units. If T is zero, it is written as S'STABLE. 

3. S'DELAYED(T) is the value of S, T time units earlier. It has the same type as S. 






These attributes are useful in detecting signal changes and will be used in the later 
chapters. 

Another useful set of attributes are those associated with arrays. For example, 
suppose that an array variable was defined as follows: 

variable A : BIT_VECTOR (0 to 15); 



Table 1. ATTRIBUTE VALUES 



Attribute 


Value 


A RANGE 


0 to 15 


A LENGTH 


16 


A LEFT 


0 


A RIGHT 


15 



Then, the set of attributes of variable A would have values indicated in Table 1. Many 
other useful attributes are defined in the "YHDL Language Reference Manual." (Ref. 
4: pp. 14-1.9] 

6. SUBPROGRAM AND PACKAGES 

Subprograms define algorithms for computing values or exhibiting certain be- 
havior. There are two forms of subprogram: procedures and functions. A procedure call 
is a statement; a function call is an expression that returns a value. The definition of a 

subprogram can be given in two parts: 

1. A subprogram declaration defining its calling conventions. 

2. A subprogram body defining its execution. 

Packages, like subprogram, may be defined in two parts. A package declaration 
defines the visible contents of a package; a package body provides the hidden details. In 
particular, a package body contains the bodies of all subprograms declared in the pack- 
age declaration. 
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package Multiplication is 

type B I TAR RAY is (INTEGER range < >) of BIT; 
function BitArrav_Int (bits: BIT_ARRAY) .return NATURAL; 
function Int_to_BitVec (int, length: NATURAL) return BIT ARRAY; 
procedure Obtain_Product (a,b: in B1T_ARRAY; 

c: out B1T_ARRAY; 
ov: out BIT); 

other declarations 



end Multiplication; 
package body Multiplication is 

function BitArray_to_Int (bits: B1T_ARRAY) return NATURAL is 
variable result: NATURAL := O'; 
begin 

for i in bits'RANGE loop 
result := result 2; 
if bits(i) = T then 
result : = result + 1; 
end if; 
end loop: 
return result; 
end BitArray_to_Int; 

function lnt_to_BitArrav 



procedure Obtain_Product( a.b: in BIT_ARRAY; 
c: out BIT_ARRAY; 
ov: out BIT) is 
variable local: INTEGER; 
constant limit: INTEGER := 2 * a'LENGTH; 

begin 

local := BitArray_to_Int(a) BitArray_to_Int(b); 
if local > limit- 1 then 
local := local mod limit; 
ov := T; 
else 

ov : = 'O'; 

end if; 

c:= lnt_to_BitArray(local, a'LENGTH); 
end Obtain_Product; 

end Multiplication; 



Figure 14. Package example 
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Shown in Figure 14 is a package consisting of a type declaration and the inter- 
faces for two functions and a procedure. The code for the functions and the procedure 
are given in the package body. If a package contains no subprograms, a package body 
is not required. The package can be accessed by placing a use clause before the interface 
description of an entity. For example, if there is a entity called MULTIPLER8 need to 
use the procedure Obtain_Product inside the Multiplication package in Figure 14. One 
could do this as follows: 

use WORK. Multiplication 
entity MULTI PLER8 is 

port (a,b: in BIT_ARRAY(0 to 7); 

prod: out BIT_ARRAY (0 to 7); 
ov: out BIT); 

end MULTIPLER8; 

architecture BEHAVIORAL of MULTIPLER8 is 
begin 

process (a,b) 

variable c: Multiplication. BIT_ARRAY (a' RANGE); 
variable loc: BIT; 
bigin 

Multiplication. Obtain_Product (a,b,c,loc); 
prod <= c after 100ns; 
ov <= loc after 100ns; 
end process; 
end BEHAVIORAL; 
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Note that when the package feature is referred to by the statement inside entity 
"Multipliers", the package name must be placed in front of the package feature in order 
to establish "visibility" between those referred items and the entity. For example, the 
procedure "Obtain_Product" used in the entity "MULTIPLER8" must have the package 
name "Multiplication" in front of it. If the clause .all is added at the end of the use 
statement, i.e., use WORK. Multiplication. all, then all the declarative items as well as any 
of its subprogram bodies contained in Multiplication package are "visible" within the 
entity MULTIPLER8. In this way, there is no need to repeat the package name in front 
of the referred package items. 

Packages are very useful language features. Design groups can use group 
standard packages that contain the type declarations and subprograms related to their 
projects. As it will be seen in modeling the EPLD, a group standard package EPROM 
will be built and extensively used in the program. 

The VHDL language defines a package STANDARD that can be used by all 
entities. This package contains the definitions for types BIT, BIT_VECTOR, 
BOOLEAN, INTEGER, REAL, CHARACTER, STRING, TIME, as well as subtype 
POSITIVE and NATURAL. 

7. OPERATORS AND CONTROL STATEMENTS 

The operators and control statements of VHDL are similar to those of the other 
high level languages, especially Ada. A complete set of operators are shown in 
Table 2. 
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Table 2. VHDL OPERATORS 



Class 


Class Members 


Logical 


not | and | or | nand 1 nor | xor 


Relational 


II 

A 

A 

II 

V 

V 
II 

II 


Adding 


+ I-I& 


Signing 


+ 1 - 


Multiplying 


| / | mode | rem 


Miscellaneous 


* | abs 



Table 3. VHDL CONTROL STATEMENTS 



IF 


LOOP 


RETURN 


CASE 


NEXT 


WAIT 




EXIT 





The control statements of VHDL are shown in Table 3. Note that most of the 
statements are very general, and only reserved word wait need a further discussion. The 
wait statement causes the suspension of a process or a procedure. In the real physical 
system, a process will frequently pause in its execution while waiting for a event to occur 
or a time period to elapse. Once the awaited event has occurred or the time period has 
elapsed, execution of the process resumes. 

In VHDL the wait syntax is shown as follows: 

wait on sensitivity_l ist until condition for time_out 

The statement suspends the process until a signal in the "sensitivity_ list” changes, at 
which time the "condition” clause is evaluated. The "condition" clause is an expression 
of type BOOLEAN. If it is TRUE, the process resumes. The "time_out" clause sets the 
maximum wait time after which the process will resume. As an example: 
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wait on x, y until (Z=0) for 100 ns; 



This statement will suspend a process until either "x" or "y" changes, then the expression 
"z = 0" is evaluated, and if the value is TRUE, the process will resume. The process will 
resume after 100 ns, even if the signals do not change or the condition is FALSE, 

Two major applications of the wait construct in modeling are the modeling of 
component interaction and oscillator behavior [Ref. 3: pp. 55], The wait statement gives 
the designer additional freedom in writing high-level behavioral models. 

B. VHDL SUPPORTING ENVIRONMENT 

The purpose of having a VHDL supporting environment is to assist hardware de- 
signers in making efficient use of the capabilities of the VHDL language. A typical 
VHDL supporting environment includes the design library, the Analyzer, and the Sim- 
ulator [Ref. 1]. Currently, there is only one VHDL supporting environment (Intermet- 
rics Standard IEEE 1076 VHDL Supporting Environment) installed at the Naval 
Postgraduate School. The following discussion will be based on this VHDL supporting 
environment. 

The Intermetrics Standard IEEE 1076 VHDL Supporting Environment consists of 
a Design Database and four software components as shown in Figure 15. A general de- 
scriptions of this VHDL supporting environment are listed as follows: 

1. Design Database. The Design Database is the central part of the system. The da- 
tabase of the hardware descriptions and related information are all stored in here. 

2. Analyzer. The Analyzer checks the hardware descriptions for syntactic and static 
semantic correctness. It also translates VHDL text to the Intermediate VHDL 
Attributed Notation (IVAN) form, and installs the translation into the Design 
Database. 

3. Simulator. The Simulator computes the behavior of a hardware model described 
in VHDL and thus provides a mean of checking dynamic semantic correctness. 
The Simulator constructs simulatable modules from IVAN data, executes these 
modules and generates reports on the runs. The Simulator consists of five sub- 
components [Ref. 5]. four of them are related to user and will be discussed as fol- 
lows: 
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YHDL support environment: (courtesy of Intermetrics Inc.) 
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a. Model Generator (MG). The Model Generator translates IVAN data into C 
source code, and compiles it to the simulation module. 

b. Build. Build links separately model-generated units and makes an executable 
Kernel in the Design Database. 

c. Sim. Sim invokes the Kernel and passes user-defined runtime parameters to the 
model. Execution of the simulation model will typically result in the production 
of a file containing signal history. 

d. Report Generator (RG). The Report Generator produces human readable re- 
ports from the file of signal histories. The selection of signals and the format 
of the report are determined by report control language file supplied by the user. 

e. VHDL Library System (VLS). VLS provides the commands necessary for the 
Design Database. 

f. Design Library Manager. The Design Library Manager is the database man- 
agement system used by the Analyzer, Simulator, and VLS to access data in the 
Design Database. 

1. SIMULATION PROCEDURE 

After a VHDL model has been created, the model needs to be simulated. The 
simulation procedure is shown in Figure 16. The first step, as shown in Figure 16, is 
to invoke the Analyzer by typing the key word VHDL followed by the program file name 
as shown in the file Batch of Appendix D. If the model has no error, an IVAN form 

data will be created. Two rules govern how VHDL design units are analyzed: 

1. A body cannot be analyzed before its interface. 

2. A unit that references a package cannot be analyzed before that package. 



After the VHDL program has been translated to the IVAN form, it then can 
be sent to the Model Generator by typing MG preceding the design VHDL unit name, 
i.e., the name of the entity or the package just been analyzed. If the VHDL unit is a 
package body, the qualifier "/body" must follow the MG key word. 

Each model when simulated needs to have a top entity. This top entity may be 
thought of as a unit that contains a model under test. The top entity itself cannot have 
any ports, but, it can have generics for passing parameters from external entity or 
VHDL supporting environment. An example is shown in the TEST_BENCH of Ap- 
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Tigure 16. Simulation procedure 

pendix B. In the structure of the top entity, the user must provide a test vector mech- 
anism in order to conduct the necessary testing. When generating this top entity, a 
qualifier " top" must follow the key word MG. 

After all the object modules have been "Model Generated", they can be "linked" 
by typing BUILD. This will produce an executable Kernel in the work library. The user 
can assign a kernel name by using the qualifier "'ker= name" following the key word 
BUILD. 
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The SIM key word will execute the Kernel and generate a Run in the working 
library. The SIM can be followed by a qualifier "/trace = select", where "select" may be 
any file name which contains the pathnames of the selected signals. Consequently, the 
Simulator will record the histories of these selected signals. In this way, the user can 
discard those irrelevant internal signals, and use the limited memory to keep the wanted 
signal information. If no trace qualifier is specified, which is the default, then the his- 
tories of all the signals will be kept. 

As mentioned above, the top entity can only have the generic declaration, which 
can receive the values provided by the SIM qualifier 7param=". With this feature, the 
user can control the simulation time or even change the operation of the model. 

Besides the non-interrupting simulation mode, the VHDL supporting environ- 
ment also provides an interactive simulation mode as shown in Figure 15. In this mode, 
the user can set the breakpoint, see the signal transitions, and change the status of the 
signals. The interactive simulation mode is a very useful tool in debugging. 

2. REPORT GENERATOR 

The Report Generator will produce a readable report file from recorded infor- 
mation. Its output signal and format are controlled by the report control file.. An ex- 
ample file is shown in Appendix B. The command to generate the report is as follows: 

RG control_file report_output_f ile 

Note that only those signals with histories preserved in the simulation can be generate 
in the report. 

The qualifier ",'map" can be used with key word SIM and RG, this qualifier can 
produce a signal map, which contains all the signals used in the model. With this signal 
map, the user can easily find out the wanted signal pathnames. An signal map example 
is shown in Appendix C. 
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3. VHDL LIBRARY SYSTEM (VLS) 

The VLS allows user to interact with the VHDL Design Database. The user can 
create his own library. A library is either a primary library or a secondary library. A 

primary library may contains the following kinds of data: 

• VHDL units, i.e., entity declarations, architecture bodies, package declarations, 
package bodies, configurations. 

• Simulation Kernel. 

• Simulation runs. 

• Other libraries. 

The secondary’ library may contain only package bodies, architecture bodies, 
and other secondary libraries. The purpose of secondary library is to allow users to 
experiment with their designs by using alternative package bodies or architecture bodies. 

The VHDL Library - System is entered by typing the VLS key word. After en- 
tering the VLS, the user can make his own library bv typing the key word MAKELIB 
followed by a physical library name, an example is shown below: 

MAKELIB «user_account. EPROM» 

Note that the symbol "< < > > " means that the name inside is the physical name of 

the created library. The user_account is the user login name. In VLS, this name is 
treated as a root library name. Every user must have a root library. In the example 
above, a library called EPROM was created under the root library. 

There are two predefined libraries: STD and WORK. STD is the logical name 
of the standard library. WORK is the logical name of the current user working library. 
The logical name can be declared as follows, 

DEFINE EPROM «user_account. EPROM» 

All the created VHDL units will be stored in the current working library whose 
default is the root library. If the user wants to change the current working library, he 
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or she has to type the key word SETLIB followed by the physical or logical library name 
in the VLS environment. For example, 

SETLIB EPROM 

will change the working library to < < user_account.EPROM > > . 

The design group members may share each others libraries. For example, as- 
sume that there are two users, "phred" and "janus". If "janus" creates a entity that uses 
the package EP310_PACK in the library EPROM, and the EPROM belongs to "phred", 
she may declare 

library EPROM; 

use EPROM. EP310_PACK. all; 

entity 



With the shared libraries, the user can avoid the redundant components and standardize 
the design. 
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III. MODELING THE EP310 



A. INTRODUCTION OF THE EP3I0 

The EP310 is an Erasable Programmable Logic Device (EPLD) manufactured by the 
Altera corporation. A user can use the CAE design tools, as shown in Figure 17, to 
configure the connections in the programmable AND logical array and the flexible 
output /feedback section of an EP310. As shown in Figure 17, the user can do his design 
via schematic capture entry, state machine entry, netlist entry, or boolean equation 
entry. Once the design was finished, it can be processed, and a JEDEC file is produced. 
The JEDEC file is a file with the standard data transfer format from the design system 
to the hardware programmer unit. An EPLD can be physically configured by a "hard- 
ware programer" with the JEDEC file as input. 

Externally, the EP310 provides 10 dedicated inputs. One of which may be used as 
a synchronous clock input. Eight I'O pins, shown in Figure 18, may be configured for 
input, output or bi-directional operation. 

Figure 18 shows the complete EP310 block diagram, and Figure 19 shows the basic 
EP310 macrocell. The internal architecture of a microcell is organized in a sum of pro- 
ducts (AND-OR) structure. Inputs to the programmable AND array, shown running 

vertically in Figure 19, come from two sources: 

1. The true and complement of the 10 dedicated input pins. 

2. The true and complement of 8 feedback signals, each one originating from a 1 O 
Architecture Control Block. 

The 36 input AND array, as shown running horizontally in Figure 19, is called the 
product term. There are 8 identical macrocells in an EP310. Each macrocell has 9 
product terms. Therefore, the total number of product term is 72. 
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EPROM 



Figure 17. BLOCK diagram of EPLD design environment 




Figure 18. EP310 block diagram: [From Ref. 6] 



37 



CLOCK 




This diagram shows one o / the eiglit Mucrocells within tho EP3I0. 



Figure 19. EP3I0 macrocell [From Ref. 6] 

At each point of intersection in the product term, as shown in Figure 19, there exist 
an EPROM type programmable connection. Initially, all connections arc made. This 
means that both the true and complement of the inputs arc connected to each product 
term. Connections arc opened, according to JED EC file during the hardware program- 
ming process. Therefore, any product term can be connected to the true or complement 
input signals. When both the true and the complement connections of any input arc left 
intact, a logical false results on the output of the product term. If both the true and 
complement connections of any input are programmed open, then a logical "don't care" 
results for that input. If all inputs of a product term are programmed open, then a 
logical true results at the output of the product term. 

As shown in Figure 19, the outputs of S product terms are ORed together, and the 
output of the OR gate is fed as an input to the I/O Architecture Control Block. In the 
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I/O Architecture Control Block the signal from the OR gate is configured for register 
or combinatorial operation via Output Selection Switches. Both types of operations can 
produce inverted output. The feedback mode of the I/O Architecture Control Block can 
be programmed as combinatorial feedback, registered feedback, I/O (i.e, directly from 
the pin), or none, via the feedback selection switches. 

Besides the normal macrocell product terms, there are additional Synchronous Pre- 
set and Asynchronous Clear product terms. These product terms are connected to all 
D-type flip-flops. When the Synchronous Preset product term is asserted HIGH, the 
output of the register will be loaded with a HIGH on the next LOW' to HIGH clock 
transition. W'hen the Asynchronous Clear product term is asserted HIGH, the output 
of the register will immediately be loaded with a LOW' independent of the clock.. An 
asynchronous clear assertion overrides a synchronous preset asseration. 

B. DEFINE THE PROBLEM 

Since an EPLD device is programmable, its configured structure varies with different 
implementations. It is desirable to model an EPLD device in VIIDL so that it is inde- 
pendent to the design environment, i.e, does not depend on the design tools. The model 
can read in a user created JEDEC file, and configure its internal connection to perform 
the user specified function. 

Besides the correct functional simulation, a model must also provide the correct 
timing simulation. When the timing of the model is violated due to register timing re- 
quirement, or bus collision, the simulator should be able to warn the user and report 
where the error occurred. 

C. DECOMPOSITION OF THE EP310 

In this research, a hierarchical structure approach was used to model the EP310. 
The top of the hierarchy is the EP310 itself. Based on Figure 18, the components in the 
next level down in the hierarchy are the Logic Array Macrocell, I O Architecture Con- 
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trol Block, and the tri-state buffer. Below the Logic Array Macrocell is the Product 
Term. Except for the tri-state bulfer, all the other next level elements are declared as 
components in the EP310's architectures as shown in Appendix A. The Logic Array 
Macrocell can be decomposed into 8 Product Term components. The I/O Architecture 
Control Block can be decomposed into the D-type flip-flop, the Output Select Unit, and 
the Feedback Select Unit as shown in Figure 19. Here, only a D flip-flop is constructed 
as a component below the I/O Architecture Control Block. The Feedback Select Unit 
and the Output Select Unit are implemented directly inside the I/O Architecture Control 
Block. 

Besides these 4 components, the EP310 model also need a place to keep the timing 
parameters and a function "READ_310" to read in the JEDEC file. All these EP310 
dependent functions and parameters were put into a package called EP310_PACK as 
shown in Figure 20. 

Functions to convert the types are needed whenever different type signals are passed 
between different entities. A resolution function to resolve the multiple-source signal is 
also required. Because of the general usability of these functions for all parts of the 
EPLD. these functions are put into a package called EPLD_PACK, which is visible to 
all the necessary components as shown in Figure 20. 

D. ESTABUISH DATA FLOW 

After the hierarchy of an EP310 was established, it is necessary to reveal the signal 
flows between different components at different hierarchical levels. Externally, the 
EP310 chip can only see 18 data pins. Ten of them are input pins and the others are 
input output pins. These 18 data pins are the data path between the outside circuit and 
the EP310 internal components. Beside these signals, an EP310 model must also receive 
a JEDEC file from the outside to simulate the designed behavior. This is done by 
passing JEDEC file data through a generic port to the simulated entity. 
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As discussed previously in this chapter, the Logic Array Macrocell has 36 signal 
lines which are derived from 18 data pins. In the VHDL model, instead of using 36 
signal lines, only 18 data lines were fed into the Logic Array Macrocell. These 18 data 
lines corresponding to the 18 data pins on the EP310. Doing it this way helps to reduce 
the excessive internal signals in the VHDL. The EP310 depending on the I/O architec- 
ture configuration can output signals through the input/output pins. 

The Logic Array Macrocell accepts 18 input signals and produce two internal 
signals. One is the tri-state buffer output enable, and the other is the ORed signal fed 
into the I O Architecture Control Block. The Logic Array Macrocell must also receive 
the corresponding JEDEC file information, i.e., 8 product term for each row of JEDEC 
file data. 

There are three input signals to the I O Architecture Control Block, one from the 
Logic Array Macrocell, one from the dedicated input pin (serve as synchronous clock), 
and the last one from the 1 O pin. The I O Architecture Control Block outputs two 
signals, one is the feedback signal, and the other is fed into the tri-state buffer. The I O 
Architecture Control Block must also receive the corresponding JEDEC file information 
that used in configuring the switches in the two select units. 

For a D flip-flop there are four input signals. One is the clock which is from the 
dedicated synchronous clock input pin. The second one is the synchronous preset which 
is from the synchronous preset product term. The last one is the asynchronous clear 
which is from the asynchronous clear product term. Although, there are no program- 
mable connections in the I) flip-flop, the JEDEC file informations is still needed to dis- 
able the assertion mechanics inside the D flip-flop, which will be discussed in the 
REGISTER TIMING section. 

The Product Term was used inside the Logic Array Macrocell and the EP310. The 
Product Term has 18 inputs signals passed from the next higher hierarchy level and 
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Figure 20. Decomposed EP310 hierarchical block diagram 



produce one output signal. The Product Term must also receive the JEDEC file infor- 
mation from the next higher level entity in order to perform the user specified functions. 

Figure 20 shows the decomposed hierarchical block diagram. As discussed above, 
the EP310 consists of 4 components, Logic Array Macrocell abbreviated as Macrocell, 
I/O Control Architecture Control Block abbreviated as IO_control, Product Term ab- 
breviated as P_term, and D flip-flop abbreviated as D_register. 

The binding of component to entities is performed by configuration specifications. 
The configuration performs a component selection kind of function. With this feature, 
interchange of components from different technologies are possible. As discussed in 
Chapter II, VHDL configuration specifications appear in the declarative part of the 
block where the corresponding component are called. In certain cases, however, it may 
be more suitable to leave the configuration unspecified and defer such decision until the 
Kernel is built [Ref. 4: pp. 1-9]. 

E. SIGNAL ASSIGNMENT 

There are two ways to assign signals. One is to gather signals with common prop- 
erties in an array. The other is to treat the signals separately. The benefit of using a 
signal array is its simplicity. But, there is a drawback. That is, each time when one of 
the elements in the array is activated, the whole array is activated. The processes asso- 
ciated with the elements of the array will be activated too often in a complex design. 
This costs a lot of simulation time. On the contrary, the single signal assignment may 
be more efficient in reducing the simulation time. But, it will make the model complex 
and hard to comprehend. In this study, the EP310 data pin signals are defined sepa- 
rately in order to reflect the real chip pinout; the rest of the signals are implemented by 
using the signal array. 
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F. JEDEC FILE INFORMATION TRANSFER 



As mentioned before, the EPLD model needs to read in the JEDEC file information 
in order to perform the designed function. There are three methods to transfer the 

JEDEC file information from outside to an entity model: 

1. Assign information via generic. 

2. Passing information via port. 

3. Passing information by predefining it as a constant in the package, and make it 
visible to the entities. 

Since the JEDEC file depends on the user's implementation, it can van - . It is not 
a good approach to declare the JEDEC file data as constants inside the package. If 
signals were used to transmit the JEDEC file data, the total number of signals including 
the implicit signals will be too large. This will affect the total simulation time, since ev- 
ery signal driver of this large set has to be checked at each delta cycle. 

Due to the reasons discussed above and the nature of the JEDEC file, passing in- 
formation via the generic is preferred. In this research, using generic to transfer JEDEC 
file information were adopted. The JEDEC file name is fed in via the EP310 generic at 
one level higher than the EP310 entity. In the EP310 declaration part a function called 
READ_JEDEC is used to read in the necessary JEDEC information. An example of 
using generics to pass the JEDEC file data to EP310 entity is illustrated on the next 
page. 
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-- inside package EP310_PACK declaration, 
function READ_JEDE( f ile_name: in string) 
return jedec_f ile_data; 

-- inside the TEST_BENCH body, 
architecture demo of test_bench is 

component EP310 generic( JEDEC_f ile_name); 

port (pinout_specif icat ion); 

-- other statement. 



begin 

EP310 generic map(user_def ined_JEDEC_f ile) 
port map(pinout_specif ication); 

-- other statement. 



end 



-- inside the EP310 entity body 
architecture STRUCTURAL of EP310 is 

constant BIT_MAP : j edec_f ile_data 

: = READ_JEDEC ( n JEDEC_f ile_name" ) ; 

The constant "BIT_\1AP" is declared to have a "jedec_file_data" type, and its value is 
assigned by the returned value from the function READ_JEDEC. After the BIT_MAP 
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is initialized, its subcomponents are passed via generics to the corresponding compo- 
nents below the EP310. Note that the "jedec_file_data" type is not defined here. Refer 
to Appendix A for the actual declaration and the exact program. 

G. MULTIPLE LEVEL LOGIC 

Because not all pins on the chip will be used, it is necessary to introduce a signal 
with three-level logic to represent the unconnected situation. The EP310 model uses a 
new type TRI, which as shown below has a three level logic: 'O', T and 'U\ 

type TRI is ( 1 U’ , ’ 0 ’ , ’ l' ); 

The 'U', depending on the location of the signal, means unconnect or undefined. 

Since the VHDL is a strongly typed language, when constructing a multiple state 
design, it is necessary to include a type conversion function to pass different type signals 
between different processes. The following is a conversion function example used in the 
EP310 model. 

function tri_to_bit( inbit: tri) return bit is 
begin 

if inbit='l' then 
return ' 1 ' ; 

else 

return 'O'; 
end if 

end bit_to_tri; 

Note that, the conversion function will return a value 'O’, if the input is 'U'. 
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II. BUSSED SIGNAL 



Shown in Figure 21 is an example where the signal "local" is driven by two sources. 
The sources of the signal "local" can come from the output of the tri-state buffer or from 
the "io_pin". Below is the statement that can model this connection. 

local<= output after tod when enable='l' else 

io_pin after tio+tin; --tio+tin is input delay 



OE (output enable) 




Figure 21. I/O primitive signal flow diagram 

Note that the statement above has implied that the "output" signal has higher pri- 
ority then the "io_pin" signal. This is reasonable, since the "output" signal drives not 
only the "local" signal but also the "io_pin" signal. Only when the tri-state buffer is 
disabled, will the "io_pin" signal value be assigned to the signal "local". 



47 



As mentioned before, the "io_pin" is a bi-directional pin driven by two sources, one 
is the tri-state buffer output, and the other is an external user input. It is driven in a 
time multiplexing sense. In order to model this circuit, it is necessary to declare the 
"io_pirr signal as a resolved signal. A resolved signal is a signal that has an associated 
resolution function. Resolution function is a user defined function that computes the 
value of a resolved signal form its multiple sources. 

There are two ways to declare a resolved signal. One is by adding a resolution 
function to the front of the type, such as: 

signal io_pin: inout RESOLVER tri; 

The other way is to declare the signal with a resolved subtype, such as: 

subtype tri_state is RESOLVER tri; 
signal io_pin: tri_state; 

The resolution function used here is called the RESOLVER. Basically, the RE- 
SOLVER will gather all the sources of the declared signal, compute it according to user 
defined rules, then return the resolved value. Below is the implementation of the func- 
tion RESOLVER. 

function RESOLVER(signal inputs: tri_vector) 
return tri_state is 

variable resolved_value: tri_state: =' U' ; 
variable flag: integer: =' 0 ' ; 
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begin 



for i in inputs' range loop 
if inputs( i)/=' U' then 
flag: = flag + 1; 
resolved_value: = inputs(i); 
end if; 
end loop; 
assert flag <= 1 

report "io_pin bus collision." 
severity FAILURE; 
return resolved_value; 
end RESOLVER; 

In the signal assignment statement the io_pin is assigned as: 

io_pin <= output after tod when oe = ’ 1 ' else 
'U 1 after tod when oe= ’ 0 f else 
•U’; 

Note that if the corresponding tri-state bulTer is enabled, i.e., oe= T and, in the mean- 
time, the user gives io_pin another assignment from the top entity, then the signal will 
have two active sources. It means that the source values are not all 'U\ In this case, 
the resolution function shown above will assert the data collision message. On the other 
hand, if only one source is active, the resolution function will output the active source 
value and assign it to the io_pin without the violation message. 

I. PRODUCT TERM INTERNAL CONNECTION 

As mentioned previously the EPLD logic array has programmable internal con- 
nections. The connections were made according to the corresponding JEDEC file spec- 
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ification. In this research a function, called check_Pterm, is used to generate the correct 

functional output. The check_Pterm function has two type of inputs: 

1. Eighteen signals from the feedback lines shown in Figure 19. 

2. Thirty-six internal connection specification defined as P_string from the JEDEC 
file. 

The check_Pterm function generates the correct value according to the specification and 
the conventional logic array rules discussed in the previous section. The main mech- 
anism of this function is to decide whether the input signal should be included by ex- 
amining the true and complement connections of the signal in the JEDEC file. Shown 
below is a portion of the decision statements used in the check_Pterm. The statemens 
are written in VHDL alike pseudo code. Refer to the package EPLD_PACK of Ap- 
pendix A for the full exact detail: 

-- begining of the decision statement, 
output: =' 1 ' ; 
i: =1; 

while i<=P_string' length loop 

if ( P_string( 2*i- 1)=' 0 ' and P_string(2*i)=' l' ) and 
( input_signal( i)=' U* or input_signal( i)=' l' ) then 

output: =' 0 ' 
exit; 
end if 

-- other decision statements, 
end loop; 
return output; 

The "P_string" in the above example is an array which contains the programmable 
AND array internal connection data. The statement "P_string (2*i-I)='0' and 
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P_string(2*i)= T " will check the connections to see whether only the complemented 
connecting point shown as P_string(2*i-1) exists. If the complemented connecting point 
exists and if the corresponding "input_signal(i)" is T or 'U' (unconnected), the output 
will be 'O'. With statements similar to the above example, the other three situations are 
checked to produce the correct output. These three situations are: a) both the true and 
the complement connecting points exists, b) both points do not exists, or c) only the true 
connecting point exists. See the function check_Pterm of Appendix A for the details. 

J. EPLD TIMING SIMULATION 

As discussed in a "EPLD timing simulation" paper [Ref. 7), the timing diagram of a 
general EP310 is shown in Figure 22. The delay time through logic array (tlad) was 
modeled as a constant. The rest of the timing parameters were like those found in the 
conventional logic circuit. Below are the description of the timing parameters shown in 
Figure 22. 

1. tin- input pad and buffer delay. 

2. tio- I O input pad delay. This delay need to be added to tin when an I/O pin is used 
as input. 

3. tod- output buffer and pad delay. 

4. txz- time to tri-state output delay. 

5. tzx- tri-state to active output delay. 

6. tlad- logic array delay. 

7. tlade- enhanced logic array delay. 

8. tsu- register setup time. 

9. th- register hold time. 

10. tclr- asynchronous register clear time. 

11. tclre- enhanced asynchronous register clear time. 

12. ties- system clock delay. 

13. tic- clock delay. 

14. tice- enhanced clock delay. 

15. tfd- feedback delay. 
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Figure 22. EPLD timing block diagram [From Ref. 7 J 

16. tell- minimum clock duration, when clock is high. 

17. tel- minimum clock duration, when clock is low. 

Since a EP310 is decomposed into four components shown in Figure 20, it is nec- 
essary to assign each component with its associated timing parameter. Figure 23 shows 
the decomposed components with their timing parameters. All the timing parameters 
used in this research can be found in [Ref. 7], 

1. REGISTER TIMING 

The most important timing problem related to a register is its setup time, hold 
time, and minimum pulse width. For example, consider the clocked register in 
Figure 24. It is a common requirement that the data input be stable for a duration of 
time prior to the clock transition that strobes the data into the register. This require- 
ment is known as the setup time of the data relative to the clock. A similar requirement 
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Figure 23. EP3I0 hierarchical block diagram with time parameter 



states that the data should remain stable a minimum amount of time after the clock 
transition which is known as the hold time requirement. 

Figure 24 shows the input specifications for the register in a typical EPLD. The 
specification says that (1) DATA should be stable for tsu nanoseconds before CLOCK 
rises, (2) DATA should be stable for tli nanoseconds after CLOCK rises, and (3) 
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CLOCK should have a minimum duration at the high level of at least tch nanoseconds. 
The following assertion statement in VHDL checks the setup time specification of the 
D register of the EP310: 

assert not( not elk' stable and clk='l' and (not d' stable(tsu)) and 
clear='0’ and (03='0’ or 04=’ O' or F2='0')) 
report "Setup Time Failure"; 

Using the DeM organ's theorem, one could convert the assertion statement to a simpler 
form 

assert ck'stable or ck =, 0' or d' stable(tsu) or clear='l' or 
( 03= ' 1 ' and 04=’ 1’ and F2='l’) 

In the above example the attribute D'STABLE(tsu) will be TRUE if and only 
if signal D has been stable for tsu time units already. Since this D register has an 
asynchronous clear, it is necessary to include "clear = '0'" in the assertion statement. 
Otherwise, when the "clear" is set to one, the D register will resume the synchronous 
clock cycle and produce the errorous result. The reason for checking the switches 03, 
04, and F2 in Figure 19 is to see if the register is selected to operate. If the macrocell 
is dedicated to perform combinational logic, then the assertion will be disabled. 
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(not clk'delay(th)'stable) and clk'delay(th)='0' 




Figure 25. Hold time timing diagram 

The hold time can be checked by using the following V11DL statement: 

assert ck'delayed(th) ' stable or ck' delayed( th)=' 0 ' or d'stable(th) or 
clear='l' or (03=' l' and 04=' l' and F2='l') 
report "Hold Time Failure"; 

The statement will check the stability of data "d" after the necessary' hold time (th). The 
hold time start from the rising edge of the clock and end at the falling of the clock as 
shown in Figure 25. If the evaluation of the statement arc false then the error will be 
reported, which means the flip-flop hold time is not satisfied. 
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Similarly, the minimum pulse-width can be checked by using the following 
statement: 

assert ck' stable or ck='l' or ck' delayed' stable(tch) or (03=' l' and 04=' l' 
and F2=' 1 ' ) 

report "Minimum pulse width failure"; 

K. COUNTER 

An EP310 was configured to implement a 7-bit counter. The JEDEC file was gen- 
erated by using the Altera logic design tool. The model was tested as a 7-bit counter. 

The simulation starts from a top entity called the "TEST_BENCH". The code of the 
”TEST_BENCH" and its architecture body are shown in Appendix B. The simulation 
result are also shown in Appendix B. Basically, the "TEST_BENCH" calls the EP310 
entity, provides the signals to the EP310's input pins, and the the external JEDEC file 
name to the EP310's generic. The user can control the simulation time via the generic 
of the "TEST_BENCH". 
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IV. MODELING THE EP1800 



A. INTRODUCTION OF THE EP1800 

The EP1800 like the EP310 discussed in Chapter III is also an Erasable Program- 
mable Logic Device with a larger number of macrocells. In the EP310 there are about 
300 gates, but in the EP1800 there are about 2100 gates [Ref. 6: pp. 2-4]. The EP1800 
has a classic programmable AND array just like the EP310. But, unlike the EP310 
which has only one D-type flip-flop, the register inside the EP1800 can be programmed 
into a D-type, T-type, JK type, or RS type flip-flop. Each register can be clocked 
asynchronously on an individual basis or synchronously on a banked register basis [Ref. 

6: pp. 2-6]. 

The block diagram of an EP1800 is shown in Figure 26. Externally, the EP1800 
provides sixteen dedicated data inputs, four of which may be used as the system clock 
inputs. There are 4S 1, 0 pins which can be individually configured to be input, output, 
or bi-directional pins. 

Internally, the EP1800 contains 48 macrocells. As shown in Figure 27 and 
Figure 2S, each macrocell contains three basic elements: a logic array, a selectable reg- 
ister element, and a tri-state 10 buffer. All the combinatorial logics are implemented 
within the logic array. For register applications each macrocell provides one of four 
possible flip-flop operations: D, T, JK, and SR. 

The EP1800 is partitioned into four identical quadrants as shown in Figure 26. 
Each quadrant contains 12 macrocclls. The macrocell input signals come from the 
EP1S00 internal bus structure. The macrocell output may drive the EP1800 external 
pins as well as the internal buses. Sixteen of the EP 1800's 48 macrocells offer increased 
speed performance through the Logic Array. These "Enhanced Macrocell" can be uti- 
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Figure 27. Local macrocell: [From Ref. 6] 

lized in places where combinatorial logic path delay is critical. There are four Enhanced 
Macrocells for each EP1800 quadrant as shown in Figure 26. A detailed delay timing 
specification of these Enhanced Macrocells are listed in the file EP1800_PACK in Ap- 
pendix A. 

There are other sixteen "Global Macrocells" that can provide dual functions. These 
Global Macrocells shown in Figure 28 implement buried logic functions, and at the same 
time serve as dedicated input pins. Thus, the EP1800 may have an additional 16 input 
pins yielding a total of 32 inputs. The Global Macrocells have the same timing charac- 
teristics as the General Macrocells [Ref 6: pp. 2-7). 

Each of the EP1800 internal flip-flops can be clocked independently or in user- 
defined groups. Any input or internal logic function may be used as a clock. These 
clock signals are activated by driving the flip-flop clock input with a clock buffer primi- 
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Figure 28. Global macrocell: [From Ref. 6] 

tivc (CLKB). In this way, the flip-flop can be configured For either positive or negative 
edge triggered operations. 

Four dedicated .system clocks, CLK1 through CLK4, provide clock signals to all the 
flip-flops. System clocks arc fed directly From the EP1800 external pins. With this direct 
connection, a system clock imposes the shortest delay than internally generated clock 
signals. There is one system clock per EP1800 quadrant. When using system clocks, the 
flip-flops arc positive edge triggered, i.c., data transitions occur on the rising edge of' the 
clock. 

B. DECOMPOSITION OF HIE EP180U 

Just like the EP310, the hierarchical structure approach is used to decompose the 
EP1800. The top level is the EP1800 itself Based on F'igurc 26 the next level down in 
the hierarchy are the Quadrants. Below this level is the Global Macrocell and the Local 
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Macrocell. The hierarchical levels lower than macrocells are similar to those structures 



in the EP310. 

The EP1800 model also needs a function READ_JEDEC to accept the JEDEC file 
and a few other necessary functions to implement the real physical device. All these 
functions together with the timing parameters and the defined types are stored in a 
package called EP1800_PACK as shown in Figure 29. 

The EP1800_PACK and the EPLD packages discussed in Chapter III are visible to 
all the necessary components. The total EP1800 hierarchical structure is illustrated in 
Figure 29. 

C. ESTABLISH DATA FLOW OF THE MODEL 

After the hierarchy of the EP1800 is established, it is necessary to identify the signal 
flows between different components. 

Looking at an EP1800 chip from outside, only 60 data pins and 4 dedicated system 
clock pins are visible as shown in Figure 30. Therefore, at the top level of the entity 
EP1800, there are 64 signals in its port declaration. These 64 signals serve as the signal 
paths between outside circuit and the EP1800 internal components. Besides these 
signals, an EP1800 model must also receive a JEDEC file from the outside to simulate 
the user-designed behavior. This is done by passing the JEDEC file name through a 
generic port to the simulated entity just like the method used for EP310. 

Inside the EP1800 entity, there are 4 quadrants. These 4 quadrants are symmetric 
in some sense, i.e., two of them are upside down. Therefore, there is only need to build 
one quadrant model. The remaining quadrants can be implemented by using the model 
directly or modifying the generic with the reverse function. The details are described in 
the EP1S00 architecture body of Appendix A. 
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Figure 30. EP 1800 chip overview: [From Ref. 6] 

The signals going into each Quadrant include the global bus inputs and a system 
clock input. Four of the Quadrant output signals are from the Global Macrocell tri- 
state buffer outputs. The rest of the 8 signals are bi-directional General Macrocell I/O 
pins. 

There are 12 macrocells inside each Quadrant. These macrocells are classified as 
Global Macrocell, General Macrocell, and Enhanced Macrocell. The structure of the 
General Macrocell is the same as the Enhanced Macrocell. The only difference between 
these two macrocells is that the Enhanced Macrocell has a shorter time delay. There- 
fore, when modeling the EP1800, it is only necessary to build the General Macrocell 
modules and the Global Macrocell module. The Enhanced Macrocell module can be 
yielded by changing the timing parameters of the General Macrocell. 

The macrocell accepts bus inputs and a system clock input. The bus inputs consist 
of 44 input signals. The macrocell outputs consists of two signals. One comes from the 
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I/O Architecture, and the other is a tri-state output enable signal. The internal struc- 
tures of the Global Macrocell and the General Macrocell are identical except that the 
General Macrocell has a feedback select switch and the Global Macrocell has an output 
enable switch. The total numbers of signal-flow control switches are the same in both 
type of macrocells. 

The I/O architecture in the macrocell accepts the ORed logic array signal, an input 
clock signal, and a register clear signal. The ORed logic array signal is generated from 
8 ORed logic-and-arrays similar to those in the EP3I0 structure. The input clock signal, 
depending on the clock select switch, is either from the quadrant synchronous clock or 
from the enable'clock logic-and-array output. 

The internal structure of the I/O architecture consists of a D-type flip-flop, logic 
gates, and 3 signal flow control switches. Because of the non-disclosure aggreement with 
the Altera corporation, the detail structure inside the I/O architecture is not discussed. 
In Appendix A, the I O architecture module of the EP1800 only shows the entity dec- 
laration part.l 

All the EP1800 internal connecting point information in the JEDEC file are passed 
to the entity via the corresponding entity generic. The parameter in the generic of 
EP1800 is a character string which can be any user-created JEDEC file name. After the 
JEDEC file name is passed into the body of the EP1800, the function READ_JEDEC 
will read in the JEDEC file data stored in the JEDEC file name. The function will assign 
this composite type (EP1800_TYPE) JEDEC file data to a constant call BIT_MAP. 
Then, like that done for the EP310, the corresponding elements of this composite con- 
stant are passed to the corresponding lower level components. For more details please 
see Appendix A. 

1 for more information please contact Prof. CIIIN-HWA LEE, Naval Postgraduate School, 
Monterey, CA 93943. 
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D. GENERAL MACROCELL AND ENHANCED MACROCELL 



As mentioned previously, th.e General Macrocell and the Enhanced Macrocell have 
the same structure but different timing parameters. In order to make the model size 
more compact and to avoid the redundant VHDL program, these two types of macro- 
cells use the same architecture body. The way to define whether the macrocell is a 
General Macrocell or an Enhanced Macrocell is by passing different timing parameters 
via generic. For Enhanced Macrocell this would look like: 

ENHANCED: LOCAL_MACROCELL generic map(P_ARRAY( 1 to 10), 

I0_ARRAY(1), tlade, tclre, tic) 

where the "tlade", "tclre", and "tic" are the enhanced timing parameters. The 
"P_ARRAY" and the "IO_ARRAY" are array types. They contain the corresponding 
product terms and I/O select unit JEDEC file data. The word "enhanced:" in front of 
the local_macrocell is referred to as the label of this component instantiation. If there 
are more than one identical component instantiation in the same block level, the labels 
with different names must be used in front of these instantiations. The General 
Macrocell and Enhanced Macrocell have the same expression but different generic val- 
ues. i.e., the timing parameters. 

E. THE REUSABLE QUADRANT MODEL 

Although the Quadrants inside the EP1800 have the same structure, the pin assign- 
ment combined with the ordered JEDEC file data makes the generic map assignment of 
Quadrant-B and Quadrant-C in the reverse order. In order to reuse the same Quadrant 
model, in this work, two "reverse functions" are built. Both "reverse functions" can re- 
verse the order of the input array. Below is one of the reverse function used in the 
EP1800 model. 
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function REVERSE(A: in IO_array_type) return 10 
_array_type is 

variable rev_array: 10_array_type( 1 to A' length); 
variable c: POSITIVE := 1; 
begin 

for i in A ' REVERSE_RANGE loop 
rev_array( c) : = A(i); 
c: — c+1; 
end loop; 
return rev_array; 
end REVERSE; 

Note that the attribute "A'REVERSE_RANGE" will output the A's range in the reverse 
order. That is, the attribute will have the range A'RIGHT downto A'LEFT if the range 
of A is ascending, or A'RIGHT to A'LEFT if the range of A is descending. These two 
reverse functions are put into the package EP1S00_PACK. 

When using the Quadrant B and C, the reverse function is placed in front of the 
generic parameter P_arrav, and IO_array as follows 

QUADRANT_B: 

QUADRANT generic map(REVERSE(P_array( range) ) , 

REVERSEC I0_array( range) ) ) 

-- port map specification 



Note that the variables inside the above two REVERSE functions have different types. 
In spite of the different types of this two arrays, the VHDL will automatically find the 
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corresponding matching function according to the input parameter type. In VHDL this 
kind of functions are called overload functions. 

F. THE EP1800 BUS STRUCTURE 

The internal bus structure of the EP1800 is more complicate than that of the EP310. 
Basically the EP1800 bus can be divided into two kinds, local bus and global bus. The 
local bus, as the name implies, only provides a signal path between macrocells within the 
same quadrant. The Global bus on the other hand provide the signal path to all the 
macrocells inside the EP1800 chip. 

The local bus consists of 12 feedback signals from 12 macrocells as shown in 
Figure 27 and Figure 28. These local feedback signals can only feed into the macrocells 
of that quadrants and cannot be accessed by the other quadrants. The local bus has two 
kinds, one is from the Global Macrocell 10 Architecture output, and the other is from 
the Local Macrocell feedback. The local bus from the Local Macrocell feedback has two 
sources, one is from the 10 Architecture output and the other is from the I/O pin. 
Which one of the two sources to use is decided by the feedback select switch as shown 
in Figure 27. This switch is configured by the JEDEC file data. 

The global bus can be divided into two classes, one is for the Global. Macrocell 
feedbacks and the other is for global dedicated input pins. The Global Macrocell feed- 
backs come from each quadrant's 4 Global Macrocells as shown in Figure 26. Since 
there are four quadrants, the total global feedbacks are 16. The global bus can be ac- 
cessed by any macrocells within the EP1800. 

The EP1800 bus signal assignments are done at two entity levels. The global bus 
signals are assigned at the EP1800 entity level as shown in the EP1800 architecture body 
of Appendix A. The local bus signals are assigned at the Quadrant entity level as shown 
in the Quadrant architecture body of Appendix A. The global bus and local bus are 
concatenated together at the Quadrant entity level as follows 
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inputs <= local_bus & global_bus; 

where the symbol "&" means concatenation. Here, this statement will connect the sec- 
ond array "global_bus" right after the first array, and form a new array "inputs". This 
new array will be fed to the macrocells. 

G. UP-DOWN COUNTER 

An application simulation of the EP1800 model was done in this study. The model 
was implemented as a 16 bits up/down counter. The counter was constructed by cas- 
cading two 8-bit counters together. The 8-bit counter used here was adopted from the 
ALTERA's TTL Macrofunction library [Ref. 8]. Figure 31 shows the 16-bit up-down 
counter block diagram and its corresponding function table. 

The simulation was done by running a top entity discussed in Chapter 11 called the 
"TESTJBENCH". The code of the "TESTBENCH" and the corresponding result are 
in Appendix B. Basically, the "TEST_BENCH" will call the EP1S00 chip and provide 
the signals and the external JEDEC file name via the port map and the generic map to 
the EP1S00. The JEDEC file can be created by any EPLD development tool as dis- 
cussed in Chapter 111. 
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V. CONCLUSIONS 



A. GENERAL 

In this thesis the general VHDL language features were introduced first. Then, the 
discussion of the EP310 and EP1800 structures leads to the modeling of these devices. * 
Study revealed a number of problems in modeling these EPLDs. The solution of these 
problems were described and tested. The modeling technique used for EP310 and 
EP1800 can be equally applied to the modeling of other types of EPLD with similar 

t 

structure. 

It is very difficult to verify the model's accuracy. One way to verify the accuracy 
of the model is by running the manufacture's hardware test vectors for the corresponding 
hardware [Ref. 9]. Since the manufacture's test vector is not available , in this study only 
the correctness of the individal modules are tested. If all the modules can work accu- 
rately, the whole model can also work accurately. 

The EP1800 and the HI* 1810 have a similar structure. The only difference between 
them is that the general macrocells in an EP1800 were replaced by the Enhanced 
Macrocells in the EP1810. The model of EP1S00 with different timing parameters can 
also be used as the EP1S10 model. 

After using the VHDL to model the EPLD hardware, there are a few comments 
about the VHDL language: 

1. The VHDL language is powerful. The VHDL has a very rich instruction set, and 
it also has the timing features in it. This makes the VHDL not only a very good 
hardware description language but also a very powerful simulation language. 

2. The VHDL is very flexible. The language allows the users to declare their own 
object types and signal attributes, which makes the modeling easier. 

3. The VHDL language can describe the hardware from three different views: behav- 
ioral. data-flow, and structural. The first two views lets the user model the hard- 
ware at an abstraction level. The hardware physical description is done at the 
structure level. 
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4. A hardware description can be detailed and accurate. The control statement and 
timing facility discussed in Chapter II allows the model to reflect not only the 
function of the hardware but also the timing characteristics. 

5. The VHDL language statement is easy to comprehend. Since the VHDL is ori- 
ginally used as a description language, it allows meaningful variable and signal 
declarations. It also allows modules to be declared as functions. This make the 
program code more readable than most of the other languages. 

6. The VHDL language learning curve is longer than those of the other languages. 
As was discussed before, the VHDL has a very rich instruction set. This sometimes 
is not a merit to the user, since rich instruction set means user need to take a longer 
time to learn more language features and rules. 

B. PROGRAM SPEED 

Like the other hardware simulation, the VHDL simulation takes a lot of time. In 
VHDL each simulation cycle is called a delta cycle. The simulation is event-driven, 
which means whenever any signal changes its value, the simulator will execute the cor- 
responding statements once. If the model is too complicated or contains too many de- 
tails which used up more internal signals, it will costs a lot of the CPU time. On the 
other hand, if the model is very abstract, i.e., modeling at the chip level or system level, 
then the simulation time can be reduced considerably. 

The models built in this study are gate level models which contain a detailed circuit 
description. This means that the models built here need more execution time than the 
other approaches. Besides long simulation time, model analyzing, generating and 
building processes also takes longer time than anticipated. 

The method of simulation developed in this work may not be the optimal one. One 
possible way to improve the simulation efficiency is to make the product-term algorithm 
more efficient. It is at the bottom of the hierarchy of the EPLD model and has the 
highest rate of execution. 

In order to save programming time and reduce programming errors, the modeler 
should thoroughly decompose the target circuit and establish the interface between all 
modules via entity declaration before actually programming the architecture body. 
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C. RECOMMENDATIONS FOR FUTURE STUDY 

The study of this thesis is concerated on the EPLD gate level modeling. But, the 
VHDL modeling technique and the modules built in this study can be applied to other 
logic system designs. The future study can be directed toward establishing a EPLD 
component library to support the increasing EPLD implementation in designs. 
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APPENDIX A. VHDL SOURCE CODE FOR EP310 AND EP1800 



MODELS 

A. VHDL SOURCE CODE FOR EPLD ^PACKAGE 



package EPROM_PACK is 

type Tri is ( ! U* , 1 0 1 , ' 1 ' ) ; 

type tri_vec is array (NATURAL range<>) of Tri; 
function resolver( signal inputs: tri_vec)return Tri; 
subtype tri_state is resolver Tri; 

type tri_vector is array (NATURAL range<>) of tri_state; 

function check_Pterm(P_string 
string; x 

tri_vector) return BIT; 

function bit_to_tri( inbit: bit) return Tri_state; 
function tri_to_bit( inbit: Tri_state) return bit; 
function trivec_to_bitvec( inbits: tri_vector) return bit_vector; 
function bitvec_to_trivec( inbits: bit_vector) return tri_vector; 

end EPROM.PACK; 

package body EPROM_PACK is 

function resolver( s ignal inputs: tri_vec) return tri is 
variable resolved_value: tri: = ! U ! ; 
variable flag: integer: = 0; 

begin ** . 

for i in inputs’ range loop 
if inputs( i)/= f U f then 
flag: = flag+1; 
resolved_value: = inputs(i); 
end if; 
end loop; 
assert flag <= 1 
report "iopin bus collision . u 
severity FAILURE; 
return resolved_value; 
end resolver; 



function check_Pterm(P_string 
string; x 

tri_vector) return BIT is 

variable P_loc: natural: =0; 
variable ou:bit:= ! l'; 
variable i: positive: =1; 
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begin 

while i <= P_string* length loop 

if (P_string( i) =l 0* and P_string( i+l)=* 0* ) then 
ou: = * 0 Y ; 
exit; 
end if; 

if(P_string( i) = ’ 1* and P_string( i+l)=' 1 1 )then 
P_loc: =P_loc+l; 
end if; 

-- select the true input. 

if(P_string( i)=' 1* and P_strin§( i+l) =l 0 * ) and 
(x((i+l)/2)=’U' or x((i+l)/2)= r 0’ ) then 
ou: = ' 0* ; 
exit; 
end if; 

-- select the complement input, 
if (P_string( i) =l 0’ and P_strin§( i+l)=’ 1* ) and 
(x((i+l)/2)= , U’ or x( ( i+l)/2)- 1* ) then 
ou: =’ 0 ’ ; 
exit; 
end if; 
i: =i+2; 
end loop; 

if P_loc = ( ( P_string* length)/2) then 
ou: = ’ 1 ’ ; 
end if; 
return ou; 
end check_Pterm; 



function bit_to_tri( inbit: bit) return Tri_state is 
begin 

if inbit =, l’ then 
return 1 1* ; 
else 

return ’0 1 ; 
end if; 

end bit_to_tri; 



function tri_to_bit( inbit: Tri_state) return bit is 
begin 

if inbit= r l* then 
return ’ 1* ; 
else 

return 1 0 ' ; 
end if; 

end tri_to_bit; 



function trivec_to_bitvec( inbits: tri_vector) return bit_vector is 
variable local: bit_vector( inbits 1 range); 
begin 

for i in inbits * range loop 
if inbits( i)=* 1 ’ then 
local( i): =’ 1 ’ ; 
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else 

local( i ) : = 1 0 1 ; 
end if; 
end loop; 
return local; 
end trivec_to_bitvec; 



function bitvec_to_trivec( inbits: bit_vector) return tri_vector is 
variable local: tri_vector( inbits 1 range); 
begin 

for i in inbits 1 range loop 
if inbits ( i)=* l r then 
local( i) : =* 1 1 ; 
else 

local( i): =l 0* ; 
end if; 
end loop; 
return local; 
end bitvec_to_trivec; 

end EPR0M_PACK; 
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B. VHDL SOURCE CODE FOR EP310 MODEL 



package EP310_PACK is 

subtype IO_string is string(l to 7); 

-- IO_string 1 to 7 are switches inside the io architecture; 
type IO_array_type is array(l to 8) of IO_string; 
subtype P_string is string( 1 to 36); 

type P_array_type is array(NATURAL range<>) of P_string; 

type EP310_TYPE is record 

P_array: P_array_type( 1 to 74); 

I0_array: IO_array_type; 
end record; 



the timing data are for EP310. 



constant 


tin: TIME: 


=10 


ns; 


constant 


tio: TIME: 


=2 


ns; 


constant 


tlad: TIME 


: =27 ns; 


constant 


tod: TIME: 


=12 


ns; 


constant 


tzx: TIME: 


=0 


ns; 


constant 


txz: TIME: 


=0 


ns; -- 


constant 


tsu: TIME: 


=10 


ns; 


constant 


th: TIME: = 


10 


ns; 


constant 


tch: TIME: 


=16 


ns; 


constant 


tics: TIME 


: =4 


ns; 


constant 


tfd: TIME: 


=5 


ns; 


constant 


tclr: TIME 


: =33 ns ; 


function 


READ_JEDEC(F 


.name 



string) return EP310_TYPE; 



tzx(here) = tzx( table) -tod;' 
txz(here) = txz( table) -tod; 



end EP310_PACK; 

use STD.TEXTIO. all; 
package body EP310_PACK is 

function READ_JEDEC( F_name 
string) return EP310_TYPE is 

file F: text is in F_name; 
variable temp: line; 

variable temp_char: character; 
variable IO_temp: string(l to 2730); 
variable EP310_MAP: EP310_TYPE; 
variable flag: boolean :=true; 
variable G00D,L_flag: boolean: =false; 
variable j ,k: integer: =1; 
begin 

-- cut out the unwanted portion, 
while flag loop 

readline(F , temp); 
read( temp , temjp_char ) ; 
if ( temp_char= *') then 
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L_f lag: =true; 
end if; 

if ( temp_char= ! L f and L_flag) then 
flag: =false; 
end if; 

assert not endfile(F) 

report "The input file is not correct"; 
end loop; 

-- extract the bit map information, 
while not endfile(F) loop 
readline( F , temp) ; 
j : =temp. all r length; 

IO_temp(k to k+j-1): =temp. all; 
k: = k+j ; 
end loop; 

for i in EP310_MAP. p_arr ay f range loop 

EP310_MAP. p_array( i): =IO_temp( l+36*( i-1) to i*36); 
end loop; 

for i in EP310_MAP. IO_arr ay T range loop 

EP310_MAP. IO_array( i): =IO_temp( 2665+7*( i-1) to 2664+7*i); 
end loop; 
return EP310_MAP; 

end READ_JEDEC; 
end EP310_PACK; 

************************************************************** 
library EP310LIB , SHU; 

use EP310LIB. EP310_PACK. all, SHU. EPROM_PACK. all; 
entity EP310 is 

generic (JEDEC: in string); 

port (pin_l ,pin_2 ,pin_3 ,pin_4 ,pin_5 ,pin_6 ,pin_7 ,pin_8 ,pin_9 ,pin_l 1 
: in tri_state; pin_12 ,pin_13 ,pin_14 ,pin_15 ,pin_16 ,pin_17 , 

pin_ 18 ,pin_19: inout tri_state ); 

end EP310; 

library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all , SHU. EPROM_PACK. all; 
architecture STRUCTURAL of EP310 is 

component MACROCELL 

generic(macro_P_array: P_array_type( 1 to 9)); 
port( a 

tri_vector( 1 to 18); 

or_out,en: out bit); 
end component; 

component P_term 

generic( P: P_string); 

port(x: in tri_vector( 1 to 18); p_out: out bit); 

end component; 

component I O_cont r o 1 

generic( 10: Io_string); 

port(clk,or_in, preset , clear 

bit; 

io_pin 
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tri_state; 

output , feedback: out tri_state); 
end component; 

signal macro_in : tri_vector( 1 to 18); 
signal oeloc,orloc: bit_vector( 1 to 8); 
signal local, output , feedback: tri_vector( 1 to 8); 
signal clear , preset: bit; 

constant BITJ1AP: EP310_TYPE := READ_ JEDEC( JEDEC ) ; 

--configuration specifications. 

for all: MACROCELL use entity EP310LIB. MACROCELL(behavioral) ; 
for all:P_term use entity EP310LIB. P_term( behavioral); 
for all: I0_C0NTR0L use entity EP310LIB. I0_C0NTR0L( behavioral_l); 
begin 

macro_in( 1)<= pin_l after tin; 
macro_in(2)<= pin_ll after tin; 
macro_in( 3)<= pin_2 after tin; 
macro_in(4)<= feedback(l); 
macro_in(5)<= pin_3 after tin; 
macro_in( 6)<= feedback(2); 
macro_in( 7)<= pin_4 after tin; 
macro_in( 8)<= feedback(3); 
macro_in( 9)<= pin_5 after tin; 
macro_in( 10)<= feedback(4); 
macro_in( 11)<= pin_6 after tin; 
macro_in( 12)<= feedback(5); 
macro_in( 13)<= pin_7 after tin; 
macro_in( 14)<= feedback(6); 
macro_in( 15)<= pin_8 after tin; 
macro_in( 16)<= feedback(7); 
macro_in( 17)<= pin_9 after tin; 
macro_in( 18)<= feedback(8); 

-- generate eight macrocells. 

M: for i in 1 to 8 generate 

macro: MACROCELL generic map( BIT_MAP. P_array( l+9*( i- 1) to 9*i)) 

port map(macro_in,orloc( i) ,oeloc( i) ); 

end generate; 

-- produce Deregister preset input. 

P: P_term generic map( BIT_MAP. P_array( 73) ) 

port map(macrOein, preset); 

-- produce D_register reset input. 

R: P_term generic map( BIT_MAP. P_array( 74) ) 

port map(macro_in, clear); 

-- generate eight IO_control element. 

CON: for i in 1 to 8 generate 

CONTROL: I0_control generic map( BIT_MAP. IO_array( i) ) 

port map( tri_to_bit(pin_l ' delayed( tics+tin) ) , 

orloc( i) , preset , clear, local ( i) , output ( i) , 
feedback( i) ); 
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end generate; 

local( 1)<= output(l) after tio+tin when 
pin_19 after tio+tin; 

local( 2)<= outpute2) after tio+tin when 
pin_18 after tio+tin; 

locaie3)<= outpute3) after tio+tin when 
pin_17 after tio+tin; 

local(4)<= outpute4) after tio+tin when 
pin_16 after tio+tin; 

locaie5)<= outpute5) after tio+tin when 
pin_15 after tio+tin; 

locaie6)<= outpute6) after tio+tin when 
pin_14 after tio+tin; 

locale 7)<= outpute7) after tio+tin when 
pin_13 after tio+tin; 

locaie8)<= outpute8) after tio+tin 
pin_12 after tio+tin; 



pin_19<= output ei) after 
, U I after tod when 

•U'; 

pin_18<= outpute2) after 
’u’ after tod when 

•u’; 



pin_17<= output(3) after 
' U' after tod when 

•U'; 



pin_16<= outpute4) after 
’ U’ after tod when 

’U’; 

pin_15<= outpute5) after 
’U’ after tod when 



pin_14<= outpute6) after 
’ U 1 after tod when 

’u’j 



pin_13<= outpute7) after 
’U 1 after tod when 
’U’; 

pin_12<= output(8) after 
’U 1 after tod when 



oeloc( 1)= ! 1 * 

oeloc(2)=* 1* 

06100 ( 3 )=' 1 ' 

oeloc(4)=’ 1* 

00100(5)=’ l 1 

oeloc( 6)=’ 1 ’ 

oeloc( 7)=’ 1 ’ 

when oeloc(8)=’ 1 ’ 

tod when oeloc(l)=’l’ else 
oeloc(l)=’0’ else 

tod when oeloc(2)=’l’ else 
oeloc(2) =, 0’ else 

tod when oeloc(3)=’l’ else 
oeloc(3)=’0 f else 

tod when oeloc(4)=’l ! else 
oeloc(4)=’0’ else 

tod when oeloc(5)=’l’ else 
oeloc(5)= f 0’ else 

tod when oeloc(4)=’l’ else 
oeloc(6)=’0’ else 

tod when oeloc(7)=’l’ else 
oeloc(7)=’0’ else 

tod when oeloc(8)=’l’ else 
oeloc(8) =, 0’ else 



else 

else 

else 

else 

else 

else 

else 

else 
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end STRUCTURAL; 
library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all, SHU. EPROM_PACK. all; 
entity MACROCELL is 

generic (macro_P_array: P_array_type( 1 to 9)); 
port( a 

tri_vector( 1 to 18); or_out,en: out bit); 
end MACROCELL; 

library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all, SHU. EPROM_PACK. all; 
architecture behavioral of MACROCELL is 
component P_term 

generic( P: P_string); 
port(x 

tri_vector(l to 18); p_out: out bit); 
end component; 

signal loc: bit_vector(l to 8); 
signal en_loc: bit; 

for all: P_term use entity EP310LIB. p_term(behavioral); 
begin 

-- generate 8 P_terms. 

P: for i in 1 to 8 generate 

element: P_term generic map(macro_P_array( i) ) 
port map( a, loc( i) ); 

end generate; 



OE: P_term generic map(macro_P_array( 9) ) 

port map(a,en_loc); 

or_out<= ' r when loc(l)=V or loc(2)='l' or loc(3)='l' 
loc(4)='l' or loc(5)='l' or loc(6)='l' or 
loc(7)='l' or loc(8)='l' else 
'O'; 

en<= en_loc after tzx; 
end behavioral; 

Vr , V Vr Vr Vr Vr “V -V V r Vr Vr Vc ir Vc -jV Vr * /V -jV it it it it it it * * * it ->V * it it it it it * it it it it * * it * * it it * * it it it * it * it 

library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all, SHU. EPROM_PACK. all; 
entity io_control is 

generic( 10: I0_string: ="0000000"); 

port( elk ,or_in, preset , clear 
bit: =t 0 1 ; io_pin: in tri_state: = f U f ; 

output , feedback: out tri_state); 
end io_control; 

library EP310LIB ,SHU; 

use EP310LIB. EP310_pack. all, SHU. EPROM_PACK. all; 
architecture BEHAVI0RAL_1 of io_control is 
component Deregister 

generic( 10: I0_string: ="0000000"); 

port(d, ck, preset , clear: in bit: =, 0 ! ;q: inout bit); 

end component; 



or 
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signal Q_loc: BIT: =* 0 1 ; 

for all: deregister use entity EP310LIB. d_register(behavioral_2); 
begin 

Dl: Deregister generic map(IO) 

port map (or_in, elk, preset , clear, Q_loc); 

process( io_pin,orein, Q_loc) 
begin 

-- OUTPUT SELECT. 

if IOCl^’O* then 

output<= bit_to_tri(not or_in) ; 
elsif I0(2)= , 0 l then 

output<= bit_to_tri(or_in) ; 
elsif 10(3) = * 0 1 then 

output<= bit_to_tri(not Q_loc) ; 
elsif I0(4)= , 0 l then 

output<= biteto_tri(Q_loc) ; 

else A • 

output<= 1 U ! ; . 

end if; - 

-- FEEDBACK SELECT, 
if I0(5) =l 0 1 then 

feedback<=b it_to_.tr i(or_in) after tfd; 
elsif I0(6) =, 0 ! then 

f eedback<=bit_to_tri(Q_loc) after tfd; 
elsif IO(7)= , O l then 
f eedback<=io_pin; 
else 

feedback<= 1 U 1 ; 
end if; 
end process ; 
end BEHAVIORAL.!; 

Vc “V -V -V * Vr V? -V ‘V it Vc Vr Vr Vr iV V- Vr -jV Vc Vc Vc -k k k k k k k k k k k k k k k Vc k k ■jV k k Vc "5 V Vr k -jV * -jV -jV 

library EP310LIB , SHU; 

use EP310LIB. EP310_PACK. all, SHU. EPROM_PACK. all; 
entity D_register is 

generic(IO: IO_string: ="1111111"); 
port( d, ck .preset , clear 
bit: =* 0 ’ ; q: out bit); 
end D_register; 

library EP310LIB , SHU; 

use EP310LIB. EP310_PACK. all , SHU. EPROM_PACK. all; 
architecture BEHAVI0RAL_2 of D_register is 
begin 

EDGE_TR I GGERED_D : 

block ((ck =, l' and not ck' stable) or clear='l') 
signal s: bit; 
begin 

-- check setup time of D_register. 

assert ck'stable or (ck =, 0') or d' stable(tsu) or (clear =, l') or 
(10(3)=' 1' and 10(4)=' l’ and 10(6)=' l') 

-- not( not ck'stable and (ck='l') and not d' stable(tsu) 

and (clear='0')) and (I0(3)='0' or I0(4) =, 0' or I0(6)='0') 
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report "Setup Time Failure. " 
severity FAILURE; 



-- check hold time of d_register. 

assert ck’ delayed( th) ’ stable or (ck’ delayed( th)=’ 0’ ) or 
d’stable(th) or (clear= ! l t ) or 
(10(3)=’ l’ and I0(4)= t l t and 10(6)=' l 1 ) 

not (not ck’ delayed( th) ’ stable and ( ck 1 delared( th) = ’ 0 r ) and 
-- not d’stable(th) and (clear=’0’) and (I0(3)=’0’ or 
-- I0(4) =1 0 1 or I0( 6)= ! 0 1 ) ) 

report "Hold Time Failure. " 
severity FAILURE; 

-- check setup time of D_register. (preset) 

assert ck stable or (ck=’0’) or preset ’ stable(tsu) or (clear=’l’) or 
(10(3)=’ l 1 and I0(4)= ! 1 1 and 10(6)=’ l 1 ) 

not( not ck 1 stable and (ck=’l’) and not preset 1 stable(tsu) 

-- and (clear=’0’) and (I0(3)=’0’ or I0(4)=V or I0(6)= , 0 t )) 
report "Setup Time Failure. n 
severity FAILURE; 

-- check hold time of deregister, (preset) 

assert ck’ delayed( th) ! stable or ( ck’ delayed( th)=’ 0 ’ ) or 
preset 1 stable(th) or (clear=’l’) or 
( 10(3)=’ l’ and 10(4)=’ 1 1 and 10(6)=’ 1 ’ ) 

not (not ck’ delayed( th) ’ stable and ( ck’ delayed( th)=’ 0 ’ ) and 
not preset ' stable( th) and (clear=’0’) and ( I0( 3 ) = 1 0 ’ or 
-- 10(4)=’ O’ or 10(6)=’ 0’)) 

report "Hold Time Failure. ” 
severity FAILURE; 

-- check minimum pulse width of deregister. 

assert ck'stable or (ck=’l’) or ck’ delayed’ stable( tch) or (10(3)=' l’ 
and 10(4)=’ 1’ and 10(6)=’ 1 ’ ) 

not (not ck’stable and ck=’l’ and ck’ delayed’ stable( tch) and 
-- ( 10(3)=’ 0’ or 10(4)=’ 0 ’ or I0(6)=’0’)) 

report "Minimum Pulse Width Failure." 
severity FAILURE; 

s<= guarded ’ 1 ’ when (preset=’l’ and clear=’0’) else 

d when (clear=’0’ and preset=’0’ and ck=’l’ and not ck’stable) 
else 

'O’ after tclr when clear=’l’ else 

s; 

q<= s; 

end block EDGE_TRIGGERED_D; 
end BEHAVI0RAL_2; 

J!« ^ 

library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all,SHU. EPR0M_PACK. all; 
entity P_term is 

generic(P: P_string); 

port(x: in tri_vector(l to 18); p_out: out bit); 

end P_term; 
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library EP310LIB , SHU; 

use EP310LIB. EP310_pack. all , SHU. EPROM_PACK. all; 

architecture behavioral of P_term is 

begin 

process(x) 

variable c: BIT; 
begin 

c: =check_Pterra(P,x); 
p_out<= c after tlad; 
end process; 
end behavioral; 
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C. VHDL MODEL FOR EP1800. 



library SHU; 

use STD. TEXTIO. all,SHU. EPROMJPACK. all; 
package EP1800_pack is 

subtype I0_string is string(l to 5); 

-- I0_string 1 to 7 are switches inside the io architecture; 
type IO_array_type is array( NATURAL range<>) of I0_string; 
subtype P_string is string( 1 to 88); 

type P_array_type is array( NATURAL range <>) of P_string; 
subtype input_line is tri_vector( 1 to 44); 

type EP1800_TYPE is record 

P_array: P_array_type( 1 to 480); 

I0_array: 10_array_type( 1 to 48); 
end record; 



-- all the time constants are for epl800-2; 



tio(here): = tin( table)+tio( table) ; 



constant tod: TIME: 
constant tzx: TIME: 
constant txz:TIME: 
constant tsu:TIME: 



constant tin: TIME: =10 ns; 
constant tio:TIME:=15 ns; - ■ 
constant t lad: TIME: =40 ns; 
constant t lade: TIME: =35 ns; 

i: =15 ns; 
i: = 15 ns; 
i:=15 ns; 

=12 ns; 
constant th: TIME: =30 ns; 
constant tch: TIME: =24 ns; 
constant tic: TIME: =40 ns; 
constant tice: TIME: =35 ns; 
constant tics: TIME: =4 ns; 
constant tfd:TIME:=10 ns; 
constant tclr: TIME: =40 ns; 
constant tclre:TIME:= 35 ns; 

here we demonstrate overload function. (which with same function name 
-- but differt input type), 
function REVERSE(A 

P_array_type( 1 to 120)) return p_array_type; 

function REVERSE(A 
IO_array_type) return 10_array_type; 
function FIND(A 

I0_string; position: in natural) 

return character; 
function READ_JEDEC(F_name 
string) return EP1800_TYPE; 



end EP1800_PACK; 

package body EP1800_PACK is 
function REVERSE(A 
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P_array_type( 1 to 120)) return P_array_type is 

variable rev_array: p_array_type( 1 to 120); 
begin 

for i in 1 to 12 loop 

rev_array( 121-10*( i) to 120-10*(i-l)) 
:=A(l+10*(i-l) to 10*(i)); 
end loop; 
return rev_array; 
end reverse; 

function REVERSE (A 

IO_array_type) return IO_array_type is 

variable rev_array: IO_array_type( 1 to A 1 length); 

variable c: positive: =1; 
begin 

for i in A f reverse_range loop 
rev_array(c): = A(i); 
c: = c+1; 
end loop; 
return rev_array; 
end reverse; 

function FIND(A 

I0_string; position: in natural) 
return character is 
begin 

return A(position); 
end FIND; 

function READ_JEDEC(F_name 
string) return EP1800_TYPE is 
file F: text is in F_narae; 
variable temp: line; 

variable temp_char: character; 
variable I0_temp: string( 1 to 42500); 
variable EP1800_MAP: EP1800_TYPE; 
variable flag: boolean : =true; 
variable GOOD, L_f lag: boolean: =false; 
variable j ,k: integer: =1; 
begin 

-- cut out the unwanted portion, 
while flag loop 

readl ine( F , temp ) ; 
read( temp , temp_char); 
if( temp_char =t * ! ) then 
L_f lag: =true; 
end if; 

if ( temp_char =t L f and L_flag) then 
flag: =f alse; 
end if; 

assert not endfile(F) 

report n The input file is not correct”; 
end loop; 

-- extract the bit map information, 
while not endfile(F) loop 
readline(F, temp); 
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j: =temp. all* length; 

IO_temp(k to k+j-1): =temp. all; 
k:= k+j; 
end loop; 

for i in EP1800_MAP. p_array T range loop 

EP1800_MAP. p_array( i): =IO_temp( l+88*( i-1) to i*88); 
end loop; 

for i in EP1800_MAP. io_array f range loop 

EP1800J4AP. I0_array(i):=I0_temp(42241+5*(i-l) to 42240+ i*5); 
end loop; 

return EP1800_MAP; 

end READ_JEDEC; 

end EP1800_pack; 

library EP1800LIB, SHU; 

use EP1800LIB. EP1800_PACK. all, SHU. EPROM_PACK. all; 

entity EP1800 is 

generic ( JEDEC : in string); 
port (pin_14 ,pin_15 ,pin_16 ,pin_17 , 
pin_19 ,pin_20 ,pin_21 ,pin_22 , 
pin_48 ,pin_49 ,pin_50 , pin_51 , 
pin_53 ,pin_54 ,pin_55 ,pin_56 
tri_state: = T \J ' ; 

pin_2 ,pin_3 ,pin_4 ,pin_5 ,pin_6 ,pin_7 , 
pin_8 ,pin_9 ,pin_10 ,pin_ll ,pin_12 ,pin_13 , 
pin_23 ,pin_24 ,pin_25 ,pin_26 ,pin_27 ,pin_28 , 
pin_29 ,pin_30 ,pin_31 ,pin_32 ,pin_33 ,pin_34 , 
pin_36 ,pin_37 ,pin_38 , pin_39 ,pin_40 ,pin_41 , 
pin_42 ,pin_43 ,pin_44 ,pin_45 ,pin_46 ,pin_47 , 
pin_57 ,pin_58 ,pin_59 ,pin_60 ,pin_61 ,pin_62 , 
pin_63 ,pin_64 ,pin_65 ,pin_66 ,pin_67 ,pin_68 
: inout tri_state: = 1 U f ); 

end EP1800; 

library EP1800LIB, SHU; 

use EP1800LIB.EP1800_pack. all, SHU. EPROM_PACK. all; 

architecture STRUCTURAL of EP1800 is 

component QUADRANT 

generic(Q__P_array: P_array_type( 1 to 120); 

Q_I0_array: 10_array_type( 1 to 12)); 
port(global_biis: in tri_vector( 13 to 44); 
quad_clk: in bit; 

io_l , io_2 , io_3 , io_4 , io_5 , io_6 , io_7 , 
io_8: inout tri_state; 
quad: out tri_vector( 1 to 4)); 
end component; 

signal global_bus: tri_vector( 13 to 44) 

: ="UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU t! ; 
signal quad_A,quad_B ,quad_C ,quad_D: tri_vector(l to 4); 
constant BIT_MAP: EP1800_TYPE: = READ_JEDEC( JEDEC); 

--conf iguation specification. 
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for 
begin 
-- Due 



all: QUADRANT use entity EP1800LIB. QUADRANT( STRUCTURAL); 

to the proprietary reason, the global bus assignment statements 
r- were removed. 

pin_10<= quad_A(l) after tod;-- (pin_10) 
pin_ll<= quad_A(2) after tod;-- (pin_ll) 
pin_12<= quad_A(3) after tod;-- (pin_12) 
pin_13<= quad_A(4) after tod; -- (pin_13) 
pin_26<= quad_B(l) after tod;-- (pin_26) 
pin_25<= quad_B(2) after tod;-- (pin_25) 
pin_24<= quad_B(3) after tod;-- (pin_24) 
pin_23<= quad_B(4) after tod;-- (pin_23) 
pin_44<= quad_C(l) after tod;-- (pin_44) 
pin_45<= quad_C(2) after tod;-- (pin_45) 
pin_46<= quad_C(3) after tod;-- (pin_46) 
pin_47<= quad_C(4) after tod;-- (pin_47) 
pin_60<= quad_D(l) after tod;-- (pin_60) 
pin_59<= quad_D(2) after tod;-- (pin_59) 
pin_58<= quad_D(3) after tod;-- (pin_58) 
pin_57<= quad_D(4) after tod; -- (pin_57) 



QA: QUADRANT 

generic map( BIT_MAP. P_array( 1 to 120), 

BIT_MAP. T0_array( 1 to 12)) 
port map(global_bus , tri_to_bit(pin_17 ) ,pin_2 ,pin_3, 
pin_4,pin_5 ,pin_6,pin_7 ,pin_8 ,pin_9 , 
quad_A); 

QB: QUADRANT 

generic map( reverse( BIT_MAP. P_array( 121 to 240)), 
reverse(BIT_MAP. I0_array( 13 to 24))) 
port map( global_bus , tri_to_bit(pin_19) ,pin_34 ,pin_33 , 
pin_32 ,pin_31 ,pin_30 ,pin_29 ,pin_28 ,pin_27 , 
quad_B); 

QC: QUADRANT 

generic map(BIT_MAP. P_array(241 to 360), 

BITJiAP. I0_array(25 to 36)) 
port map(global_bus , tri_to_bit(pin_51) ,pin_36 ,pin_37 , 
pin_38 ,pin_39 ,pin_40 ,pin_41 ,pin_42 ,pin_43 , 
quad_C); 

QD: QUADRANT 

generic map( reverse(BIT_MAP. P_array(361 to 480)), 
reverse(BIT_MAP. I0_array(37 to 48))) 
port map(global_bus , tri_to_bit(pin_53) ,pin_68 ,pin_67 , 
pin_66 ,pin_65 ,pin_64 ,pin_63 ,pin_62 ,pin_61 , 
quad_D); 



end STRUCTURAL; 

‘V ‘V "jV Vr Vr ->V V? ■>: - Y *V ->Y ■>’? -jY 'V * * * Vc * ?Y * VoY * Vr * ?Y * Vo Y -jY ->Y * Vc Ve Vc Vr Vr Vr Vr Vr tY Vr Vc Vr Vr Vr Vr 

library EP1800LIB, SHU; 

use EP1800LIB. EP1800_PACK. all, SHU. EPROM_PACK. all; 
entity QUADRANT is 

generic(Q_P_array: P_array_type( 1 to 120); 
Q_I0_array: 10_array_type( 1 to 12)); 
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port (global_bus: in tri_vector( 13 to 44); 
quad_clk: in bit; 

io_l , io_2 , io_3 , io_4 , io_5 , io_6 , io_7 , 
io_8: inout tri_state; 
quad: out tri_vector( 1 to 4)); 
end QUADRANT; 



library EP1800LIB, SHU; 

use EP1800LIB. EP1800_PACK. all , SHU. EPROM_PACK. all; 
architecture STRUCTURAL of QUADRANT is 

component LOCAL_MACROCELL 

generic( P_array: P_array_type( 1 to 10); 10: I0_string; 
t_lad: TIME: =tlad; t_clr: TIME: =tclr; 
t_ic: TIME: =tic); 
port( inputs 

input_line; quad_clk: in bit; V- 

oe, output: out bit); 
end component; 

component GL0BAL_MACR0CELL 

generic( P_array: P_array_type( 1 to 10); 10: I0_string; 
t_lad: time: =tlade; t_clr: time: =tclr; 
t_ic: time: =tic); 
port( inputs 

input_line; quad_clk: in bit; 

oe, output: out bit); 
end component; 



signal oe,M_output: bit_vector( 1 to 12); 
signal local_bus: tri_vector( 1 to 12); 
signal local: tri_vector( 1 to 8); 
signal inputs: input_line; 

for all: L0CAL_MACR0CELL 

use entity EP1800LIB. L0CAL_MACR0CELL( structural); 

for all: GL0BAL_MACR0CELL 

use entity EP1800LIB. GL0BAL_MACR0CELL( structural) ; 



begin 

inputs<= local_bus & global_bus; 

M1_E: L0CAL_MACR0CELL generic map(Q_P_array( 1 to 10) ,Q_I0_array( 1) , 

t lade, tc Ire, t ice) 
port map ( inputs ,quad_c lk, 

oe( 1) ,M_output( 1) ); 

M2_E: L0CAL_MACR0CELL generic map( Q_P_array( 1 1 to 20) ,Q_I0_array( 2) , 

tlade, tclre, tice) 
port map ( inputs ,quad_clk, 

oe(2) ,M_output(2)); 

M3_E: L0CAL_MACR0CELL generic map( Q_P_array( 2 1 to 30) ,Q_I0_array( 3) , 
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M4_E: 

M5_GE: 

M6_GE: 

M7_GE: 

M8_GE: 

M9_GL: 

».M10_GL: 

M11_GL: 

M12_GL: 

io_ 

io_ 

io 



tlade, tclre,tice) 
port map ( inputs ,quad_c Ik, 

oe(3) ,M_output(3)); 

LOCAL_MACROCELL generic map(Q_P_array(31 to 40) ,Q_I0_array(4) , 

tlade ,tclre,tice) 
port map ( inputs ,quad_clk, 

oe(4) ,M_output(4)); 

LOCAL_MACROCELL generic map(Q_P_array(41 to 50) ,Q_I0_array(5) ) 
port map ( inputs ,quad_c lk, 

oe(5) ,M_output(5) ); 

L0CAL_MACR0CELL generic map(Q_P_array(51 to 60) ,Q_I0_array(6) ) 
port map ( inputs ,quad_clk, 

oe( 6) ,M_output(6) ); 

L0CAL_MACR0CELL generic map(Q_P_array( 61 to 70) ,Q_I0_array( 7) ) 
port map ( inputs ,quad_clk, 
oe( 7) ,M_output( 7) ) ; 

L0CAL_MACR0CELL generic map( Q_P_array( 71 to 80) ,Q_I0_array(8)) 
port map ( inputs ,quad_clk, 

oe( 8) ,M_output( 8) ); 

GL0BAL_MACR0CELL generic map( Q_P_array( 81 to 90) ,Q_I0_array(9)) 
port map ( inputs ,quad_clk, 

oe(9) ,M_output(9)); 



GLOBAL_MACROCELL 

generic map(Q_P_array(91 to 100) ,Q_I0_array( 10)) 
port map ( inputs ,quad_clk, 

oe( 10) ,M_output( 10) ); 



GLOBAL_MACROCELL 

generic map(Q_P_array( 101 to 110) ,Q_I0_array( 11)) 
port map ( inputs , quad_clk, 

oe( 11) ,M_output( 11) ); 



GLOBAL_MACROCELL 

generic map(Q_P_array( 111 to 120) ,Q_I0_array( 12) ) 
port map ( inputs ,quad_clk, 

oe( 12) ,M_output( 12) ); 

,1<= bit_to_tri(M_output( 1) ) after tod when oe(l)= , l' else 
'U 1 after tod when oe(l) =, 0' else 
'U'j 

,2<= bit_to_tri(H_output(2)) after tod when oe(2)='l' else 
'U' after tod when oe(2) =, 0' else 

V; 

3<= bit_to_tri(M_output( 3)) after tod when oe(3)='l' else 
'U 1 after tod when oe(3) =, 0' else 
’U'j 
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io_4<= bit_to_tri(M_output(4) ) after tod when oe(4)= , l t else 
, U* after tod when oe(4) =, 0' else 
T U T ; 

io_5<= bit_to_tri(M_output(5) ) after tod when oe(5)= , l t else 
T U* after tod when oe(5)= , 0 t else 
•U*; 

io_6<= bit_to_tri(M_output(6)) after tod when oe(6)= T l T else 
T U T after tod when oe(6)= , 0' else 
! U ! ; 

io_7<= bit_to_tri(M_output(7)) after tod when oe(7)= , l l else 
* U * after tod when oe(7) = , 0 t else 
1 U* ; 

io_8<= bit_to_tri(M_output( 8) ) after tod when oe(8)= , l t else 
T U ! after tod when oe(8)= , 0 l else 

'U's 



local( 1)<= bit_to_tri(M_output( 1) ) 
io_l after tio; 

local(2)<= 
local( 3)<= 
local(4)<= 
local(5)<= 
local( 6)<= 
locale 7)<= 
locale 8)<= 
local_buse 1)<= 
local_bus( 2)<= 
local_bus( 3)<= 
local_buse4)<= 



after tio when oe(l)= , l ! else 

else 
else 
else 
else 
else 
else 
else 



else 

else 

else 

else 



bit_to_tri(M_output( 2) ) after tio when oe(2) =, l' 
io_2 after tio; 

bit_to_tri(M_output( 3) ) after tio when oe(3) =t 1* 
io_3 after tio; 

bit_to_tri(M_output( 4) ) after tio when oe(4)= , l' 
io_4 after tio; 

bit_to_tri(M_output(5) ) after tio when oe(5)= , l’ 
io_5 after tio; 

bit_to_tri(M_output( 6) ) after tio when oe(6)= , l' 
io_6 after tio; 

bit_to_tri(M_output( 7) ) after tio when oe(7) =, l' 
io_7 after tio; 

bit_to_tri(M_output( 8) ) after tio when 06 ( 8 ) = ^' 
io_8 after tio; 

local( 1) when f ind(CL.IO_array( 1) ,4) = ’ 0* 
bit_to_tri(M_output( 1) ) after tfd; 

local(2) when f ind(Q_IO_array( 2) ,4)=' 0* 
bit_to_tri(M_output( 2) ) after tfd; 

local(3) when f ind(Q_I0_array( 3) ,4)=' 0 ' 
bit_to_tri(M_output( 3) ) after tfd; 

local( 4) when f indeQ_IO_arraye 4) ,4)=' 0 T 
bit_to_trieM_outpute4) ) after tfd; 
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local_bus(5)<= local(5) when f ind( Q_IO_array( 5) ,4)=' O' else 
bit_to_tri(M_output(5)) after tfd; 

local_bus(6)<= local(6) when f ind(Q_IO_array(6) ,4)=' O' else 
bit_to_tri(M_output( 6) ) after tfd; 



local_bus( 7)<= local(7) when f ind(Q_IO_array( 7) ,4)=' O' else 
bit_to_tri(M_output( 7)) after tfd; 

local_bus( 8)<= local(8) when find(Q_I0_array(8) ,4)='0' else 
bit_to_tri(M_output(8)) after tfd; 



local_bus(9)<= bit_to_tri(M_output(9) ) after tfd; 
local_bus( 10)<= bit_to_.tr i(M_output( 10)) after tfd; 
local_bus( 11)<= bit_to_tri(M_output( 11) ) after tfd; 
local_bus( 12)<= bit_to_tri(M_output( 12) ) after tfd; 



quad(l)<= bit_to_tri(M_output(9) ) when oe(9)='l' else 
'U 1 when oe(9)= , 0 1 else 
'U'; 

quad(2)<= bit_to_tri(M_output( 10) ) when oe(10)=' l' else 
'U' when oe(10)='0’ else 
’U'; 

quad(3)<= bit_to_tri(M_output( 11) ) when oe(ll)=' l' else 
'U 1 when oe(ll) =, 0' else 
’U'; 



quad(4)<= bit_to_tri(M_output( 12) ) when oe(12)='l' else 
1 U ' when oe(12)='0' else 
’U'; 



end STRUCTURAL; 









library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPROM_PACK. all; 
entity LOCAL_MACROCELL is 

generic(P_array: P_array_type( 1 to 10); 10: IO_string; 
t_lad: time: =tlad; t_clr: time: =tclr; 
t_ic: time: =tic); 
port( inputs 
input_line; quad_clk 
bit; 

oe , output : out bit); 
end LOCAL_MACROCELL; 



library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all , SHU. EPROM_PACK. all; 
architecture STRUCTURAL of LOCAL_MACROCELL is 



component P_term 

generic(P: P_string; t_lad: time: =tlad); 
port(x 

input_line; p_out: out bit); 
end component; 
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bit; 



component I0_C0NTR0L 

generic ( 10: I0_string; t_clr: time: =tclr); 
port ( or_in, elk, clear 



end component; 



output: out bit); 



signal local: bit_vector( 1 to 10); 
signal or_out,clk: bit; 



for all: 
for all: 



begin 

PI: 


P_term 


P2: 


P_term 


P3: 


P_term 


P4: 


P_term 


P5: 


P_term 


P6: 


P_term 


P7: 


P_term 


P8: 


P_term 


CLR_P: 


P_term 






0ECK_P: 


P_term 



P_term use entity EP1800LIB. P_term(behavioral) ; 

I0_C0NTR0L use entity EP1800LIB. I0_C0NTR0L(behavioral); 

generic map(P_array( 1) ,t_lad) 
port map( inputs , local( 1) ) ; 
generic map(P_array(2) ,t_lad) 
port map( inputs , local( 2) ) ; 
generic map( P_array( 3) , t_lad) 
port map( inputs , local( 3) ) ; 
generic map( P_array( 4) , t_lad) 
port map( inputs , local(4) ); 
generic map(P_array(5) ,t_lad) 
port map( inputs , local(5) ); 
generic map( P_array( 6) , t_lad) 
port map( inputs , local( 6) ) ; 
generic map(P_array( 7) ,t_lad) 
port map( inputs , local( 7) ); 
generic map(P_array( 8) ,t_lad) 
port map( inputs , local( 8) ) ; 
generic map(P_array( 9) , t_lad) 
port mape inputs , local( 9) ) ; 
generic map( P_array( 10) , t_ic) 
port map( inputs , local( 10) ) ; 



or_out< =, l’ when (local(l) or locaie2) or local(3) 
or local(4) or local(5) or local(6) 
or local(7) or local( 8) )=* 1 T else 
’O’; 



0ECK_S: process(quad_clk, local ( 10) ) 
begin 

if 10(2)=’ O’ then 

clk<= quad_clk after tics; 
oe<= local( 10) after tzx; 
else 

clk<= local( 10); 
oe<= r 1 1 after tzx; 
end if; 

end process 0ECK_S; 



101: I0_C0NTR0L generic map( 10, t_clr) 

port map(or_out ,clk, local(9) , output); 



end STRUCTURAL; 

V % Vr #V y ? Vw % Vr V* Vwf Vc V? Vc VcVc #Wc V? VSr Vf Vc 
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library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all , SHU. EPROM_PACK. all; 
entity GLOBAL_MACROCELL is 

generic(P_array: P_array_type( 1 to 10); 10: I0_string; 
t_lad: time: =tlad; t_clr: time: =tclr; 
t_ic: time: =tic); 
port( inputs 
inputs line; quad_clk 
bit; 

oe , output: out bit ) ; 
end GL0BAL_MACR0CELL; 



library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all , SHU. EPR0M_PACK. all; 
architecture STRUCTURAL of GL0BAL_MACR0CELL is 

component P_term 

generic(P: P_string; t_lad: time: =tlad); 
port(x: in input_line; p_out: out bit); 

end component; 



component I0_C0NTR0L 

generic( 10: I0_string; t_clr: time: =tclr) ; 
port(or_in, elk, clear: in bit; 

output: out bit); 
end component; 

signal local: bit_vector( 1 to 10); 
signal or_out ,clk,oeck: bit; 



for all: 
for all: 



begin 

PI: 


P_term 


P2: 


P_term 


P3: 


P — term 


P4: 


P_term 


P5: 


P_term 


P6: 


P_term 


P7: 


P_term 


P8: 


P_term 


CLR_P: 


P_term 


0ECK_P: 


P_term 



P_term use entity EP1800LIB. P_term(behavioral); 

I0_C0NTR0L use entity EP1800LIB. I0_C0NTR0L(behavioral); 

generic map( P_array( 1) ) 
port map( inputs , local( 1) ); 
generic map( P_array( 2) ) 
port map(inputs, local(2)); 
generic map(P_array(3) ) 
port map( inputs , local( 3) ) ; 
generic mapeP_arraye4) ) 
port map( inputs , locale^) ); 
generic mapeP_arraye5) ) 
port mape inputs , locale 5) ); 
generic mape P_arraye 6) ) 
port map( inputs , locale 6) ) ; 
generic mape P_arraye 1 ) ) 
port mape inputs , locale 7) ); 
generic mape P_arraye 8) ) 
port mape inputs , locale 8) ); 
generic mapeP__array(9) ) 
port map( inputs , locaie9) ); 
generic mape P_arraye 10) , tic) 
port map( inputs , local( 10) ) ; 



or_out<= , l' when e locale 1) or locaie2) or local(3) 
or locaie4) or locaie3) or locaK6) 
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or local(7) or local(8)) =t l ! else 
1 0 1 ; 

OECK_S: process(quad_clk, local( 10) ) 
begin 

if 10(2) = * 0 1 then 

clk<= quad_clk after tics; 
oeck<= local(lO); 
else 

clk<= local(lO); 
oeck< =t 1 T ; 
end if; 

end process 0ECK_S; 

0E_S: process(oeck) 

begin 

if I0(4)= t 0 t then 
oe<= oeck; 
else 

oe<= ! 0 T ; 
end if; 

end process 0E_S; 

I0_1: I0_C0NTR0L generic map(IO) 

port map(or_out , elk, local(9) , output); 

end STRUCTURAL; 
library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPR0M_PACK. all; 
entity I0_C0NTR0L is 

generic( 10: I0_string; t_clr: time: =tclr); 
port (or_in, elk, clear 
bit; output: out bit); 
end I0_C0NTR0L; 

-- For architecture body source code please contect Prof. CHIN-HVA LEE, 
-- Naval Postgraduate School, Monterey, CA, 93943. 



library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPR0M_PACK. all; 
entity D_register is 

generic( 10: character: = ! 0’ ; t_clr: time: =tclr); 
port(d, elk, clear 
bit:= T 0’; q: out bit); 
end D_register; 

library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPR0M_PACK. all; 

architecture BEHAVIORAL of D_register is 

begin 

EDGE_TRIGGERED_D: 

block ((clk=’l T and not clk T stable) or clear= ! l T ) 
signal s: bit; 
begin 
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-- check next setup time of D_re^ister. 

assert elk 1 stable or (clk =, O r ) or d 1 stable( tsu) or 
(clear= ! l T ) or 10= 1 1 ’ 

not( not clk f stable and (clk= T l 1 ) and not d 1 stable( tsu) 
and (clear= , 0 1 )) and IO^O 1 ) 
report "Setup Time Fialure. " 
severity FAILURE; 



-- check hold time of d_register. 

assert clk ? delayed( th) Y stable or (clk t delayed(th)= 1 0 f ) or 
d’stable(th) or 
(clear =t 1 T ) or I0= f l f 

-- not (not elk 1 delayed(th) ’ stable and (clk’delared(th)= f 0 r ) and 
not d’stable(th) and (clear= 1 0 1 ) and IO= T 0 1 ) 
report "Hold Time Failure. " 
severity FAILURE; 

»„ ( 

-- check minimum pulse-width of d_register. 

assert clk'stable or (clk='l') or elk' delayed' stable(tch) or I0='l' 
not (clk'stable and (clk='l' and elk'delayed' stable(tch) and 
10=' O') 

report "Minium pulse width failure" 
severity FAILURE; 

s<= guarded ' 0 ' after t_clr when clear='l' else 
d when (clear='0' and clk='l' and not clk'stable) else 
s; 

q<= s; 



end block EDGE_TRI GGERED_D; 
end BEHAVIORAL; 

****************************************************** 
library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPR0M_PACK. all; 
entity P_term is 

generic(P: P_string; t_lad: time: =tlad); 
port(x 

input_line; p_out: out bit); 
end P_term; 



library EP1800LIB, SHU; 

use EP1800LIB. EP1800_pack. all, SHU. EPR0M_PACK. all; 

architecture behavioral of P_term is 

begin 

process(x) 

variable c: BIT; 
begin 

c: =check_Pterm(P,x); 
p_out<= c after t_lad; 
end process; 
end behavioral; 

************************************************ 
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APPENDIX B. VHDL CODE FOR TESTJBENCH 
A, VHDL SOURCE CODE FOR TOP ENTITY DECLARATION, 



-- NOTE: In the top-level design unit there can not have TIME generic 
-- parameter, other wise there will have a error message in model 
-- generate(MG) state and the MG process will stop without creating any 
-- object file. 

entity TESTJBENCH is 

generic (ck_rate: integer: = 20000000; 
term^sim: integer: = 10; 

delay: integer: =1000); -- delay unit ns. 
end TESTJBENCH; 
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B. TEST BENCH ARCHITECTURE BODY FOR EP310 



library EP310LIB , SHU; 

use EP310LIB. ep310_pack. all ,SHU. EPROM.PACK. all; 
architecture ep310 of test_bench is 

component ep310 generic( JEDEC: in string); 

p o r t ( p in_ 1 , p in_2 , p in_3 , p in_4 , p in_5 , p in_6 , p in_ 7 , 
pin_8 ,pin_9 ,pin_ll: in tri_state; 
pin_12 ,pin_13 ,pin_14,pin_15 ,pin_16 ,pin_17 , 
pin_18 ,pin_19: inout tri_state ); 

end component; 

signal p in_ 1 , p in_2 , p in_3 , p in_4 , p in_5 , p in_6 , 

pin_7 ,pin_8 ,pin_9 ,pin_ 11: tri_state: = 1 U 1 ; 
signal pin_12 ,pin_13 ,pin_14,pin_15 ,pin_16 , 

pin_17 ,pin_18 ,pin_19: resolver tri_state:= ! U ! ; 
signal input: tri_vector( 1 to 10); 
signal io: tri_vector( 1 to 8); 
signal count: integer : =0; 

signal clock: bit:=’0’; 

for all : ep310 use entity EP310LIB. ep310( structural); 
begin 



EP1:EP310 generic map( !, cntr7. jed M ) 

port map(pin_l ,pin_2 ,pin_3 ,pin_4,pin_5 ,pin_6 ,pin_7 , 
pin_8,pin_9 ,pin_ll, 

pin_12 ,pin_13 ,pin_14,pin_15 ,pin_16 ,pin_17 , 
pin_18,pin_19); 

CLOCK_GENERATOR: process( clock) 
begin 

clock<= not clock after 1 sec / ck_rate; 
pin_l<= bit_to_tri( clock); 
end process CL0CK_GENERAT0R; 

pin_3<=’l’; --after 2 sec /ck_rate; ENABLE. 

pin_2<=’0’; --after 1 sec/ck_rate; RESET. 

TERMINATE: process( count ) 
begin 

assert (count /= term_sim) 

report ’Simulation is done. ”; 
end process TERMINATE; 

I0_INPUT: block( clock = ’l’) 
begin 

pin_19<= guarded ! l’; 
end block I0_INPUT; 

count<= count+1 after delay^ns; 

input<= pin_l & pin_2 &. pin_3 6c pin_3 & pin_5 6c pin_6 6c pin_7 
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& pin_8 & pin_9 & pin_ll; 

io <= pin_12 & pin_13 & pin_14 & pin_15 & pin_16 & pin_17 & pin_18 
& pin_19; 

end ep310; 
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DEC-05-1988 17:18:20 



VHDL Report Generator 



PAGE 1 



Vhdl Simulation Report 

Kernel Library Name: «SHU»TEST_EP3 
Kernel Creation Date: DEC-05-1988 
Kernel Creation Time: 17: 11: 16 
Run Identifer: 1 
Run Date: DEC-05-1988 
Run Time: 17: 11: 16 

Report Control Language File: TEST_EP310. RCL 
Report Output File : TEST_EP3. RPT 

Max Time: 9223372036854775807 
Max Delta: 2147483646 



Report Control Language : 

simulation_report s is 
begin 

page_width is 72^ 
select_signal : c T,=: >pin_19; 

select_signal : "clk"=>pin_l; 

select_signal : pin_2,pin_3; 

select_signal : *pin_12 - pin_18"=> io( 1 to 7); 

sample_signals by_event in ns; 

end; 



Report Format Information : 

Time is in NS. relative to the start of simulation 

Time period for report is from 0 NS to End of Simulation 

Signal values are reported by event ( 1 1 indicates no event ) 
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DEC-05-1988 17:18:20 



VHDL Report Generator 



PAGE 2 



TIME 




(NS) 


c elk PIN_2 


0 


'U' ’U' 'U' 


+1 


'o 1 ! o f 


39 




+ 1 




50 




+1 


’1’ ’1' 


76 




+ 1 




100 




+ 1 


'o' 


150 




+ 1 


'1' 


176 




+ 1 




200 




+ 1 


'o' 


250 




+1 


'1' 


276 




+1 




300 




+ 1 


'o' 


350 




+ 1 


'1' 


376 




+1 




400 




+ 1 


'o' 


450 




+ 1 


'1' 


476 




+1 




500 




+1 


'o' 


550 




+ 1 


'1' 


576 




+1 




600 




+ 1 


'o' 


650 




+1 


'1' 


676 




+1 




700 




+1 


'o' 


750 




+1 


'1' 


776 





SIGNAL NAMES 

PIN_3 pin_12 - pin_18( 1 TO 7) 

'U' "UUUUUUU" 

’1' 

"ooooooo" 

" 0000001 " 



" 0000010 " 



" 0000011 " 



"ooooioo" 

" 0000101 " 



" 0000110 " 



"0000111" 
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+1 I ”0001000" 

800 j 

+1 | ’O’ 
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C. TEST_BENCH ARCHITECTURE BODY FOR EP1800 



library EP1800LIB, SHU; 

use EP1800LIB.EP1800_PACK. all, SHU. EPROM JPACK. all; 
architecture epl800 of test_bench is 
component EP1800 

generic (JEDEC : in string); 

port (pin_14 ,pin_15 ,pin_16 ,pin_17 , 
pin_19 ,pin_20 ,pin_21 ,pin_22 , 
pin_48 ,pin_49 ,pin_50 ,pin_5 1 , 
pin_53 ,pin_54,pin_55 ,pin_56 
tri_state: - 0 ! ; 

pin_2 ,pin_3 ,pin_4,pin_5 ,pin_6 ,pin_7 , 
pin_8 ,pin_9 ,pin_10 ,pin_l 1 ,pin_12 ,pin_13 , 
pin_23 ,pin_24,pin_25 ,pin_26 ,pin_27 ,pin_28, 
pin_29 ,pin_30 ,pin_31 ,pin_32 ,pin_33 ,pin_34, 
pin_36 ,pin_37 ,pin_38 ,pin_39 ,pin_40 ,pin_41 , 
pin_42 ,pin_43 ,pin_44 ,pin_45 ,pin_46 ,pin_47 , 
pin_57 ,pin_58 ,pin_59 ,pin_60 ,pin_61 ,pin_62 , 
pin_63 ,pin_64 ,pin_65 ,pin_66 , pin_67 ,pin_68 
: inout tr instate: = 1 0 1 ); 
end component; 

s ignal DNUP , CLOCK , LOAD , RESET 

: tri_state: =t 0 1 ; 

signal Q: tri_vector(l to 16): ="0000000000000000"; 
signal D: tri_vector( 1 to 16) : = n 0000000000000000 M ; 
signal ck: bit : = 1 0 1 ; 
signal c: positive: =1; 

-- configuration specification 

for all : epl800 use entity EP1800LIB. epl800(structural); 
begin 

-- use named association interface list, associated lists are according to 
-- chip map from ALTERA Design Processor Utilization Report. 

EP1:EP1800 generic map( "count, jed") 

port map(pin_2=>Q(9) ,pin_3=>Q( 10) ,pin_4=>Q( 11) , 
pin_5=>Q( 12) ,pin_6=>Q( 13) ,pin_7=>Q( 14) , 
pin_8=>Q( 15) ,pin_9=>Q( 16) ,pin_10=>Q( 1) , 
pin_ll=>Q(2) ,pin_12=>Q( 3) ,pin_13=>Q( 7 ) , 
pin_l6=>DNUP,pin_17=>CLOCK,pin_19=>D(8), 
pin_20=>D( 9) ,pin_21=>D( 10) ,pin_22=>D( 11) , 
pin_23=>D( 1) ,pin_24=>D( 2) ,pin_25=>D( 3) , 
pin_26=>D( 7) , pin_48=>D( 12) ,pin_49=>D( 13) , 
pin_50=>D( 14) ,pin_51=>D( 15 ) ,pin_53=>CL0CK, 
pin_54=>D( 16) ,pin_55=>LOAD,pin_56=>RESET, 
pin_57=>Q(4) ,pin_58=>Q(5) ,pin_59=>Q( 6) , 
pin_60=>Q(8) ,pin_66=>D(4) ,pin_67=>D( 5 ) , 
pin_68=>D( 6) ) ; 

CL0CKJ3ENERAT0R: process(ck) 
begin 

ck<= not ck after delay*ns; 
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CLOCK<= bit_to_tri( ck); 
end process CLOCK_GENERATOR; 

DNUP <= ! 1 ! ; --up counter. 

RESET <= f l f when c = 1 else 
'O'; 

LOAD <= f l f when c = 2 else 
1 0 f ; 

c<= c+1 after delay*ns; 

TERMINATE: process(ck) 
begin 

assert (NOW /= term_sim*delay*ns) 
report "simulation is done. 
end process TERMINATE; 
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DEC-05-1988 17:19:44 



VHDL Report Generator 



PAGE 1 



Vhdl Simulation Report 

Kernel Library Name: «SHU»TEST_COUNT 
Kernel Creation Date: NOV-24-1988 
Kernel Creation Time: 14: 37: 26 

Run Identifer: 1 
Run Date: NOV-24- 1988 
Run Time: 14: 37: 26 

Report Control Language File: TEST_EP1800. RCL 
Report Output File : TEST_COUNT. RPT 

Max Time: 9223372036854775807 
Max Delta: 2147483646 



Report Control Language : 

simulation_report C0UNT_UP is 
begin 

page_width is 72: 
select_signal : "RE ,,: =>RESET; 
select_signal : n clk ,,= >CL0CK; 
select_signal : n L0 ,,= >L0AD; 
select_signal : n DNUP"=> DNUP; 
select_signal : Q; 
sample_signals by_event in ns; 

end; 



Report Format Information : 

Time is in NS relative to the start of simulation 

Time period for report is from 0 NS to End of Simulation 

Signal values are reported by event ( 1 1 indicates no event ) 
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DEC-05-1988 17: 19: 44 



VHDL Report Generator 



PAGE 2 



TIME 


1 — 
1 






SIGNAL NAMES- 




(NS) 




RE 


elk 


LO DNUP 


QC 1 TO 16) 


0 




'o' 


'O' 


! 0’ 1 0 1 


" uuuuuuuuuuuuuuuu' 


+1 




'1' 




'1' 




55 










"oooooooouuuuuuuu' 


70 












+ 1 










"oooooooooooouuuu 1 


75 










"oooooooooooooooo 1 


1000 












+ 1 




'o' 


'1' 


'1' 




2000 












+ 1 






'o' 


'o' 




3000 












+1 






'1' 






3019 










”1000000000.000000' 


4000 


1 










+ 1 


1 




'o' 






5000 


1 










+1 






'1' 






5019 










"0100000000000000 1 


6000 












+1 






'o' 






7000 












+ 1 






'1' 






7019 










”1100000000000000' 


8000 












+ 1 


1 




'o’ 






9000 


1 










+ 1 






'1' 






9019 










"0010000000000000' 


10000 












+ 1 






'o' 






11000 












+ 1 






'1' 






11019 


1 








”1010000000000000' 


12000 


1 










+ 1 






'o' 






13000 


1 










+ 1 






'1' 






13019 










"0110000000000000' 


14000 


1 










+ 1 






'o' 






15000 












+ 1 






'1' 






15019 










"1110000000000000 1 


16000 












+ 1 






'o' 






17000 












+ 1 






'1' 






17019 










”0001000000000000' 


18000 
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'o' 



+ 1 I 

19000 | 

+ 1 I 

19019 



1001000000000000 " 
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APPENDIX C. EXAMPLES OF SIGNAL SELECT FILE AND SIGNAL 

MAP FILE 



A. SIGNAL SELECT FILE 

-- selected trace signals for test_epl 800 are 
: RESET; 

: CLOCK; 

: LOAD; 

: DNUP; 

: Q; 
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B. SIGNAL MAP OF THE TEST EP3 MODEL 

DEC-13-1988 14:26:12 VHDL Simulator PAGE 1 

SIGNAL NAME MAP 
KERNEL = «SHU»TEST EP3 



: CLOCK ; 

: COUNT ; 

: INPUTC1 TO 10) ; 

: 10(1 TO 8) ; 

: PIN_1 ; 

: PIN_11 ; 

: PIN_12 ; 

: PIN_13 ; 

: PIN_14 ; 

: PIN_15 ; 

: PIN_16 ; 

: PIN_17 ; 

: PIN_18 ; 

: PIN_19 ; 

: PIN_2 ; 

: PIN_3 ; 

: PIN_4 ; 

: PIN_5 ; 

: PIN_6 ; 

: PIN_7 ; 

: PIN_8 ; 

: PIN_9 ; 

I0_INPUT : GUARD ; 

/EP1 : CLEAR ; 

/EP1 : FEEDBACK(1 TO 8) ; 

/EP1 : LOCAL(l TO 8) ; 

/EP1 : MACRO_IN( 1 TO 18) ; 

/EP1 : OELOC( 1 TO 8) ; 

/EP1 : ORLOC( 1 TO 8) ; 

/EP1 : OUTPUT(l TO 8) ; 

/EP1 : PIN_1 ; 

/EP1 : PIN_11 ; 

/EP1 : PIN_12 ; 

/EP1 : PIN_13 ; 

/EP1 : PIN_14 ; 

/EP1 : PIN_15 ; 

/EP1 : PIN_16 ; 

/EP1 : PIN_17 ; 

/EP1 : PIN_18 ; 

/EP1 : PIN_19 ; 

/EP1 : PIN_2 ; 

/EP1 : PIN_3 ; 

/EP1 : PIN_4 ; 

/EP1 : PIN_5 ; 

/EP1 : PIN_6 ; 

/EP1 : PIN_7 ; 

/EP1 : PIN_8 ; 

/EP1 : PIN_9 ; 

/EP1 : PRESET ; 

/EP1. CON(l) : CLK ' TYPE_C0NV_7 9_C ; 
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/EPl.CON(l) : PIN_1'DELAYED_79_A 
/EP1. CON(l) /CONTROL 
/EP1. CON( 1) /CONTROL 
/EP1. CON(l) /CONTROL 
/EP1. CON(l) /CONTROL 
/EP1. CON( 1) /CONTROL 
DEC-13-1988 14:26:12 



CLEAR 
CLK ; 

FEEDBACK ; 

IO_PIN ; 

OR_IN ; 

VHDL Simulator 
SIGNAL NAME MAP 
KERNEL = «SHU»TEST EP3 



PAGE 2 



/EP1. CON(l) /CONTROL : OUTPUT ; 

/EP1. CON( l)/CONTROL : PRESET ; 

/EP1. CON(l) /CONTROL : Q_LOC ; 

/EP1. CON( l)/CONTROL/Dl : CK ; 

/EP1. CON( 1) /CONTROL/DI : CLEAR ; 

/EP1. CON( l)/CONTROL/Dl : D ; 

/EP1. CON( 1) /CONTROL/DI : PRESET ; 

/EP1. CON( 1) /CONTROL/DI : Q ; 

/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRI GGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 1 ) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( l)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TR I GGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TR I GGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TR I GGERED_D 
/EP1. CON( 1) /CONTROL/D 1. EDGE_TRI GGERED_D 
/EP1. CON( 2) : CLK 1 TYPE_CONV_7 9_C ; 

/EP1. CON( 2) : PIN_1'DELAYED_79_A ; 

/EP1. CON( 2) /CONTROL : CLEAR ; 

/EP1. CON( 2) /CONTROL : CLK ; 

/EP1. CON( 2) /CONTROL : FEEDBACK ; 

/EP1. CON( 2) /CONTROL : IO_PIN ; 

/EP1. CON( 2) /CONTROL : OR_IN ; 

/EP1. CON( 2) /CONTROL : OUTPUT ; 

/EP1. CON( 2) /CONTROL : PRESET ; 

/EP1. CON( 2)/CONTROL : Q_LOC ; 

/EP1. CON( 2)/CONTROL/Dl : CK ; 

/EP1. CON( 2)/CONTROL/Dl : CLEAR ; 

/EP1. CON( 2) /CONTROL/D 1 : D ; 

/EP1. CON( 2) /CONTROL/DI : PRESET ; 

/EP1. CON( 2)/CONTROL/Dl : Q ; 

/EP1. CON( 2 ) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TR I GGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TRIGGERED_D 



CK ' DELAYED_26_5 ; 
CK'DELAYED_26_7 ; 
CK'DELAYED_26_7’STABLE_26_9 ; 
CK ' DELAYED_43_D ; 

CK ' DELAYED_43_F ; 

CK ' DELAYED_43_F ' STABLE_43_H ; 
CK'DELAYED_52_I ; 
CK'DELAYED_52_I’STABLE_52_K ; 
CK'STABLE_13_1 ; 

CK' STABLE. 18_3 ; 
CK'STABLE_35_B ; 
CK'STABLE_52_L ; 
CK'STABLE_59_M ; 

D'STABLE_18_2 ; 

D'STABLE_26_4 ; 

GUARD ; 

PRESET' STABLE_35_A ; 

PRESET' STABLE_43_C ; 

Si 



CK ' DELAYED_26_5 ; 
CK'DELAYED_26_7 ; 

CK ' DELAYED_26_7 ' STABLE_26_9 ; 
CK ' DELAYED_43_D ; 
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/EP1. C0N(2)/C0NTR0L/D1.EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/D 1 . EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/D 1. E D GE_TR I GGE RE D_D 
/EP1. CON( 2)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 2)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 2) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON(2)/CONTROL/Dl. EDGE_TRIGGERED_D 



CK'DELAYED_43_F ; 

CK ' DELAYED_43_F ’ STABLE_43_H ; 
CK'DELAYED_52_I ; 
CK'DELAYED_52_I'STABLE_52_K ; 
CK' STABLE. 13_1 ; 
CK'STABLE_18_3 ; 
CK'STABLE_35_B ; 
CK'STABLE_52_L ; 
CK'STABLE_59_M ; 

D' STABLE. 18_2 ; 
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SIGNAL NAME MAP 



KERNEL = «SHU»TEST EP3 



/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
/EP1. 
, /EPl. 

; : spi. 

/EPl. 

/EP1. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 

/EPl. 



CON( 2) /CONTROL/D 1. EDGE.TRI GGERED.D 
CON( 2) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 2) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON(2)/CONTROL/Dl. EDGE.TRIGGERED.D 
CON( 2) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3) : CLK 1 TYPE.CONV.7 9.C ; 

CON( 3) : PIN.l 1 DELAYED.79.A ; 



CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON( 3) /CONTROL 
CON ( 3 ) / CONTROL / D 1 
CON( 3 ) /CONTROL/DI 
CON( 3) /CONTROL/D 1 
CON( 3) /CONTROL/DI 
CON( 3 ) /CONTROL/DI 



CLEAR ; 

CLK ; 

FEEDBACK ; 
IO.PIN ; 
OR.IN ; 
OUTPUT ; 
PRESET ; 
Q.LOC ; 

CK ; 
CLEAR ; 
D ; 

PRESET 
Q 



CON( 3)/ CONTROL/ D 1 . EDGE.TR I GGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3 ) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3 ) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TR I GGERED.D 
CON( 3 ) / CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3 ) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3 ) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3 ) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/D 1. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 3) /CONTROL/DI. EDGE.TRIGGERED.D 
CON( 4) : CLK' TYPE.CONV.7 9.C ; 

CON( 4) : PIN.l ' DELAYED.79.A ; 

CON( 4) /CONTROL : CLEAR ; 



D' STABLE.26.4 ; 

GUARD ; 

PRESET' STABLE.35.A ; 
PRESET' STABLE.43.C ; 
S ; 



CK' DELAYED.26.5 ; 

CK' DELAYED.26.7 ; 

CK ' DELAYED. 2 6. 7 ' STABLE.26.9 ; 
CK' DELAYED.43.D ; 

CK' DELAYED.43.F ; 

CK' DELAYED.43.F' STABLE.43.H ; 
CK ' DELAYED.5 2.1 ; 

CK ’ DELAYED.5 2.1 ' STABLE.5 2.K ; 
CK' STABLE.13.1 ; 

CK' STABLE.18.3 ; 

CK' STABLE.35.B ; 

CK' STABLE.5 2.L ; 

CK* STABLE.5 9.M ; 

D' STABLE. 18.2 ; 

D' STABLE. 2 6.4 ; 

GUARD ; 

PRESET' STABLE.35.A ; 

PRESET 'STABLE.43.C ; 

s ; 
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/EP1.C0NC 4) /CONTROL : CLK ; 

/EP1. CON( 4) /CONTROL : FEEDBACK ; 

/EP1. CON( 4) /CONTROL : IO_PIN ; 

/EP1. CON( 4) /CONTROL : OR_IN ; 

/EP1. CON( 4) /CONTROL : OUTPUT ; 

/EP1. CON( 4) /CONTROL : PRESET ; 

/EP1. CON( 4) /CONTROL : Q_LOC ; 

/EP1. CON( 4) /CONTROL/DI : CK ; 

/EP1. CON( 4) /CONTROL/D 1 : CLEAR ; 

/EP1. C0N(4)/C0NTR0L/D1 : D ; 

/EP1. CON( 4) /CONTROL/DI : PRESET ; 

/EP1. CON( 4) /CONTROL/DI : Q ; 

/EP1. CON( 4)/CONTROL/Dl. EDGE_TRI GGERED_D : CK' DELAYED_26_5 ; 

/EP1. C0N(4) /CONTROL/DI. EDGE_TRIGGERED_D : CK 1 DELAYED_26_7 ; 
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/EP1. CON( 4) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 4)/C0NTR0L/Dl. E DGE_TR I GGERE D_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 4) /CONTROL/DI. E DGE_TR I GGERE D_D 
/EP1. CON( 4) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 4)/C0NTR0L/Dl. EDGE_TRIGGERED_D 
/EP1. C0N(4)/C0NTR0L/D1. EDGE_TR I GGERED_D 
/EP1. CON( 4)/C0NTR0L/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 4) /CONTROL/D 1. E DGE_TR I GGERE D_D 
/EP1. CON( 4) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TR I GGE RE D_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TR I GGERED_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 4) /CONTROL/DI. EDGE_TR I GGERE D_D 
/EP1. C0N(4) /CONTROL/DI. EDGE_TR I GGERED_D 
/EP1. CON( 4)/C0NTR0L/Dl. EDGE_TR I GGERED_D 
/EP1. CON(5) : CLK 1 TYPE_CONV_7 9_C ; 
/EPl.CON(5) : PIN_1 ' DELAYED_79_A ; 

/EP1. CON( 5) /CONTROL : CLEAR ; 

/EP1. CON( 5) /CONTROL : CLK ; 

/EP1. CON( 5) /CONTROL : FEEDBACK ; 

/EP1. CON( 5) /CONTROL : IO_PIN ; 

/EP1. CON( 5) /CONTROL : OR_IN ; 

/EP1. CON( 5) /CONTROL : OUTPUT ; 

/EP1. CON( 5) /CONTROL : PRESET ; 

/EP1. CON( 5) /CONTROL : Q_LOC ; 

/EP1. CON(5) /CONTROL/DI : CK ; 

/EP1. CON(5)/CONTROL/Dl : CLEAR ; 

/EP1. CON(5) /CONTROL/DI : D ; 

/EP1. CON(5) /CONTROL/DI : PRESET ; 

/EP1. CON( 5) /CONTROL/D 1 : Q ; 

/EP1. CON(5 )/CONTROL/Dl. EDGE_TR I GGERE D_D 
/EP1. CON( 5) /CONTROL/D 1. EDGE_TR I GGERED_D 
/EP1. CON(5) /CONTROL/DI. EDGE_TRIGGERE D_D 
/EP1. CON( 5) /CONTROL/DI. E DGE_TR I GGERE D_D 
/EP1. CON( 5) /CONTROL/DI. EDGE_TR I GGERED_D 
/EP1. CON( 5 ) /CONTROL/DI. E DGE_TR I GGERE D_D 



CK'DELAYED_26_7'STABLE_26 9 ; 
CK ' DELAYED_43_D ; 

CK ' DELAYED_43_F ; 

CK ' DELAYED_43_F ' STABLE_43_H ; 
CK ' DELAYED_52_I ; 
CK'DELAYED_52_I'STABLE_52_K ; 
CK'STABLE_13_1 ; 
CK’STABLE_18_3 ; 
CK'STABLE_35_B ; 

CK ' STABLE_52_L ; 
CK'STABLE_59_M ; 

D'STABLE_18_2 ; 

D’STABLE_26_4 ; 

GUARD ; 

PRESET' STAB LE_35_A ; 

PRESET' STABLE_43_C ; 

s ; 



CK ' DELAYED_26_5 ; 

CK ' DELAYED_26_7 ; 

CK ' DELAYED_26_7 ' STABLE_26_9 ; 
CK ' DELAYED_43_D ; 

CK ' DELAYED_43_F ; 

CK ' DELAYED_43_F ' STABLE_43_H ; 
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/EP1. CON( 5) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/DI. EDGE_TR I GGERED_D 
/EP1. CON(5) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/DI. EDGE_TRIGGERED_D 
/ E P 1 . C ON ( 5 ) / C ONTROL/ D 1 . E DGE.TR I GGE RE D_D 
/EP1. CON( 5) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON(5)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. C0N(5) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 5) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. C0N(5) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6) : CLK'TYPE_CONV_79_C ; 
/EP1.CONC6) : PIN_1 ' DELAYED_79_A ; 



/EP1. CON( 6) /CONTROL 
/EP1. CON( 6) /CONTROL 
/EP1. CON( 6) /CONTROL 
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CLEAR ; 
CLK ; 
FEEDBACK 



CK ' DELAYED_52_I 
CK ' DELAYED_52_I ' STABLE_52_K , 
CK'STABLE_13_1 
CK'STABLE_18_3 
CK ' STABLE_35_B 
CK ' STABLE_52_L 
CK'STABLE_59_M 
D’STABLE_18_2 ; 

D ' STABLE_26_4 ; 

GUARD ; 

PRESET' STABLE_35_A 
PRESET’ STABLE_43_C 
S ; 
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/EP1. CON( 6) /CONTROL : IO_PIN ; 

/EP1. CON( 6) /CONTROL : OR_IN ; 

/EP1. CON( 6) /CONTROL : OUTPUT ; 

/EP1.CONC 6) /CONTROL : PRESET ; 

/EP1. CON( 6) /CONTROL : Q_LOC ; 

/EP1. CON( 6) /CONTROL/D 1 : CK ; 

/EP1. CON( 6) /CONTROL/D 1 : CLEAR ; 

/EP1. CON( 6) /CONTROL/D 1 : D ; 

/EP1. CON( 6) /CONTROL/DI : PRESET ; 

/EP1. CON( 6) /CONTROL/D 1 : Q ; 

/EP1. CON( 6) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/D 1. E D GE_TR I GGERE D_D 
/EP1. CON( 6) /CONTROL/D 1. E D GE_TR I GGERE D_D 
/EP1. CON( 6) /CONTROL/D 1. E DGE_TR I GGE RE D_D 
/EP1. CON( 6) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 6)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON(6) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/DI. E D GE_TR I GGERE D_D 
/EP1. CON( 6) /CONTROL/DI. E D GE_TR I GGE RE D_D 
/EP1. CON( 6) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/D 1. E DGE_TR I GGE RE D_D 
/EP1. CON( 6) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 6) /CONTROL/DI. E D GE_TR I GGE RE D_D 
/EP1. CON( 7 ) : CLK'TYPE_CONV_79_C ; 

/EP1. CON( 7 ) : PIN_1 ' DELAYED_79_A ; 

/EP1. CON( 7) /CONTROL : CLEAR ; 

/EP1. CON( 7) /CONTROL : CLK ; 

/EP1. CON( 7) /CONTROL : FEEDBACK ; 



CK'DELAYED_26_5 ; 
CK'DELAYED_26_7 ; 
CK'DELAYED_26_7'STABLE_26_9 ; 
CK'DELAYED_43_D ; 

CK ' DELAYED_43_F ; 
CK’DELAYED_43_F' STABLE_43_H ; 
C K ' DE LA YE D_5 2_ I ; 
CK'DELAYED_52_I'STABLE_52_K ; 
CK'STABLE_13_1 ; 
CK'STABLE_18_3 ; 
CK'STABLE_35_B ; 
CK'STABLE_52_L ; 
CK'STABLE_59_M ; 

D' STABLE. 18_2 ; 

D ' STABLE_26_4 ; 

GUARD ; 

PRESET' STABLE_35_A ; 

PRESET 'STABLE_43_C ; 

S ; 
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/EP1. CON( 7) /CONTROL 
/EP1. CON( 7) /CONTROL 
/EP1. CON( 7) /CONTROL 
/EP1. CON( 7) /CONTROL 
/EP1. CON( 7) /CONTROL 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP 1. CON( 7 ) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7 ) / CONTROL/DI 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/ D1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
/EP1. CON( 7) /CONTROL/D 1 
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IO_PIN ; 

OR_IN ; 

OUTPUT ; 

PRESET ; 

Q_LOC ; 

CK ; 

CLEAR ; 

D ; 

PRESET ; 

Q ; 

EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRI GGERED_D 
EDGE_TRIGGERED_D 
EDGE_TRIGGERED_D 
EDGE_TR I GGERED_D 
EDGE TRIGGERED D 



EDGE_TR I GGERED_D 
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CK ' DELAYED_26_5 ; 

CK ' DELAYED_26_7 ; 

CK ' DELAYED_26_7 ' STABLE_26_9 
CK 1 DELAYED_43_D ; 

CK ' DELAYED_43_F ; 

CK 1 DELAYED_43_F ' STABLE_43_H 
CK'DELAYED_52_I ; 
CK’DELAYED_52_I ' STABLE_52_K , 
CK' STABLE. 13_1 
CK’STABLE_18_3 
CK'STABLE_35_B 
CK'STABLE_52_L 
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/EP1. CON( 7) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 7 ) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 7) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 7) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 7) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 7) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 7 ) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 8) : CLK 1 TYPE_CONV_7 9_C ; 

/EP1. CON( 8) : PIN_1 ' DELAYED_79_A ; 

/EP1. CON( 8) /CONTROL : CLEAR ; 

/EP1. CON( 8) /CONTROL : CLK ; 

/EP1. CON( 8) /CONTROL : FEEDBACK ; 

/EP1. CON( 8) /CONTROL : IO_PIN ; 

/EP1. CON( 8) /CONTROL : OR_IN ; 

/EP1. CON( 8) /CONTROL : OUTPUT ; 

/EP1. CON( 8) /CONTROL : PRESET ; 

/EP1. CON( 8) /CONTROL : Q_LOC ; 

/EP1. CON( 8) /CONTROL/D 1 : CK ; 

/EP1. CON( 8) /CONTROL/D 1 : CLEAR ; 

/EP1. CON( 8) /CONTROL/D 1 : D ; 

/EP1. CON( 8) /CONTROL/D 1 : PRESET ; 

/EP1. CON( 8) /CONTROL/D 1 : Q ; 

/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON ( 8 ) / CONTROL/D 1 . EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 8 ) / CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 



CK ' STABLE_5 9_M ; 

D' STABLE. 18_2 ; 
D’STABLE_26_4 ; 

GUARD ; 

PRESET' STABLE_35_A ; 
PRESET' STABLE_43_C ; 
S ; 



C K ' DE LAYE D_ 2 6_5 ; 
CK'DELAYED_26_7 ; 

CK ' DELAYED_26_7 ' STABLE_26_9 ; 
CK ' DELAYED_43_D ; 

CK ' DELAYED_43_F ; 

CK ' DELAYED_43_F ' STABLE_43_H ; 
CK'DELAYED_52_I ; 
CK'DELAYED_52_I’STABLE_52_K ; 



114 



/EP1. C0N(8)/C0NTR0L/D1.EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 8)/CONTROL/Dl. EDGE_TR I GGERED_D 
/EP1. CON( 8) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 8)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON(8) /CONTROL/DI. EDGE_TRIGGERED_D 
/EP1. CON( 8)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/D 1. EDGE_TRIGGERED_D 
/EP1. CON( 8) /CONTROL/DI. E DGE_TR I GGE RE D_D 
/EP1. CON(8)/CONTROL/Dl. EDGE_TRIGGERED_D 
/EPl.M(l) /MACRO : A( 1 TO 18) ; 

/EP1. M( l)/MACRO : EN ; 

/EPl.M(l) /MACRO : EN_LOC ; 

/EPl.M(l) /MACRO : LOC(l TO 8) ; 

/EP1.M( l)/MACRO : OR_OUT ; 

/EP1. M( l)/MACRO. P( 1)/ELEMENT : P_OUT 
/EP1. M( l)/MACRO. P( 1)/ELEMENT : X(1 TO 
/EP1. M( l)/MACRO. P(2)/ELEMENT : P_OUT 
/EP1. M( l)/MACRO. P(2)/ELEMENT : X(1 TO 
/EPl.M(l) /MACRO. P( 3) /ELEMENT : P_OUT 
/EP1. M(l) /MACRO. P( 3) /ELEMENT : X(1 TO 
/EP1. M(l) /MACRO. P( 4) /ELEMENT : P_OUT 
/EP1. M( l)/MACRO. P(4)/ELEMENT : X(1 TO 
/EP1. M(l) /MACRO. P( 5) /ELEMENT : P_OUT 
/EP1. M( 1 ) /MACRO. P( 5 ) /ELEMENT : X( 1 TO 
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CK'STABLE_13_1 
CK' STABLE_18_3 
CK'STABLE_35_B 
CK'STABLE_52_L 
CK'STABLE_59_M 
D'STABLE_18_2 ; 

D ' STABLE_26_4 ; 

GUARD ; 

PRESET' STAB LE_35_A 
PRESET' STABLE_43_C , 
S : 



18) 

18) 

18) 

18) 



18) ; 
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/EP1. M( 1 ) /MACRO. P( 6 ) /ELEMENT 
/EP1. M( l)/MACRO. P( 6) /ELEMENT 
/EP1. M( l)/MACRO. P( 7) /ELEMENT 
/EP1. M(l) /MACRO. P( 7) /ELEMENT 
/EP1. M( 1) /MACRO. P( 8) /ELEMENT 
/EP1. M(l) /MACRO. P( 8) /ELEMENT 
/EP1. M( 1) /MACRO/ OE : P_OUT ; 
/EP1. M( l)/MACRO/OE : X(1 TO 18) 
/EP1. M( 2) /MACRO : A( 1 TO 18) ; 
/EP1. M(2)/MACRO : EN ; 

/EP1. M(2)/MACRO : EN_LOC ; 

/EP1. M(2)/MACRO : LOC(l TO 8) ; 
/EP1. M( 2) /MACRO 



p 


OUT ; 




X( 


1 


TO 


18) 


p 


OUT ; 




X( 


1 


TO 


18) 


p 


.OUT : 




X( 


1 


TO 


18) 



: OR OUT ; 










P(l) /ELEMENT : 


P 


OUT ; 




P( 1) /ELEMENT : 


X( 


1 


TO 


18) 


P( 2) /ELEMENT : 


P 


OUT ; 




P( 2) /ELEMENT : 


X( 


1 


TO 


18) 


P( 3) /ELEMENT : 


P 


OUT ; 




P( 3) /ELEMENT : 


X( 


1 


TO 


18) 


P( 4) /ELEMENT : 


P 


OUT ; 




P( 4) /ELEMENT : 


X( 


1 


TO 


18) 


P( 5) /ELEMENT : 


p 


OUT ; 




P( 5) /ELEMENT : 


X( 


1 


TO 


18) 


P( 6) /ELEMENT : 


p 


OUT ; 




P( 6) /ELEMENT : 


X( 


1 


TO 


18) 


P( 7) /ELEMENT : 


p 


.OUT ; 
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/EP1. M( 2) /MACRO. P( 7) /ELEMENT 
/EP1. M( 2) /MACRO. P( 8) /ELEMENT 
/EP1. M( 2) /MACRO. P( 8) /ELEMENT 
/EP1. M( 2)/MACRO/OE : P_OUT ; 
/EP1. M(2)/MACRO/OE : X(1 TO 



X(1 TO 18) ; 
P_OUT ; 

X(1 TO 18) ; 



/EP1. M( 3) /MACRO 
/EP 1 . M( 3 ) /MACRO 
/EP1. M( 3) /MACRO 
/EP1. M( 3) /MACRO 
/EP1. M( 3) /MACRO 



A( 1 TO 18) 
FN • 

EN_LOC ; 
LOC( 1 TO 8 
OR OUT : 



18) 



) ; 



P( D/ELEMENT : 


P 


.OUT ; 




P( 1) /ELEMENT : 


X( 


1 


TO 


18) 


P( 2) /ELEMENT : 


P 


OUT ; 




P( 2) /ELEMENT : 


X( 


1 


TO 


18) 


P( 3) /ELEMENT : 


P 


OUT ; 




P(3)/ELEMENT : 


X( 


1 


TO 


18) 


P(4)/ELEMENT : 


P 


OUT ; 




P( 4) /ELEMENT : 


X( 


1 


TO 


18) 


P( 5) /ELEMENT : 


p 


OUT ; 




P( 5) /ELEMENT : 


X( 


1 


TO 


18) 


P( 6) /ELEMENT : 


p 


OUT ; 




P( 6) /ELEMENT : 


X( 


1 


TO 


18) 


P( 7) /ELEMENT : 


p 


OUT ; 




P( 7) /ELEMENT : 


X( 


1 


TO 


18) 


P( 8) /ELEMENT : 


p 


OUT ; 




PC 8) /ELEMENT : 


X( 


i 


TO 


18) 


OE : P OUT ; 











/EP1. M(3) /MACRO/OE : X( 1 TO 18) 
/EP1. M(4)/MACRO : A( 1 TO 18) ; 
/EP1. M(4)/MACR0 : EN ; 



DEC-13-1988 14:26:12 



VHDL Simulator 
SIGNAL NAME MAP 
KERNEL = «SHU»TEST EP3 



/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 

/EP1. 



M( 4) /MACRO 
M( 4) /MACRO 
M( 4) /MACRO 



EN_LOC ; 
LOC( 1 TO 8) 



: OR OUT ; 










PCI) /ELEMENT : 


P 


OUT ; 




PC 1) /ELEMENT : 


X( 


1 


TO 


18) 


P( 2) /ELEMENT : 


P 


OUT ; 




P( 2) /ELEMENT : 


X( 


1 


TO 


18) 


PC 3) /ELEMENT : 


P 


OUT ; 




P( 3) /ELEMENT : 


X( 


1 


TO 


18) 


P( 4) /ELEMENT : 


P 


OUT ; 




PC 4) /ELEMENT : 


xc 


1 


TO 


18) 


P( 5) /ELEMENT : 


p 


OUT ; 




P( 5) /ELEMENT : 


X( 


1 


TO 


18) 


P( 6) /ELEMENT : 


p 


OUT ; 




P( 6) /ELEMENT : 


X( 


1 


TO 


18) 


P( 7) /ELEMENT : 


p 


OUT ; 




P( 7) /ELEMENT : 


X( 


1 


TO 


18) 


PC 8) /ELEMENT : 


p 


OUT ; 




PC 8) /ELEMENT : 


X( 


1 


TO 


18) 



M( 4) /MACRO/OE : P_OUT ; 

M( 4) /MACRO/OE : X( 1 TO 18) 
M( 5 ) /MACRO : A( 1 TO 18) ; 
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/EP1. M( 5) /MACRO : EN ; 

/EP1. M(5)/MACRO : EN_LOC ; 

/EP1. M(5)/MACRO : LOC( 1 TO 8) ; 

/EP1. M(5 ) /MACRO : OR_OUT ; 

/EP1. M(5)/MACRO. P( 1)/ELEMENT : P_OUT ; 

/EP1. M(5 )/MACRO. P( 1)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO. P(2)/ELEMENT : P_OUT ; 

/EP1. M(5)/MACRO. P(2)/ELEMENT : X(1 TO 18) ; 

/EP1. M( 5 ) /MACRO. P( 3 ) /ELEMENT : P_OUT ; 

/EP1. M(5 ) /MACRO. P( 3)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO. P(4)/ELEMENT : P_OUT ; 

/EP1. M(5)/MACRO. P(4)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO. P(5)/ELEMENT : P_OUT ; 

/EP1. M( 5) /MACRO. P( 5) /ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO. P(6)/ELEMENT : P_OUT ; 

/EP1. M(5)/MACRO. P(6)/ELEMENT : X(1 TO 18) ; 

/EP1. M(5)/MACRO. P(7)/ELEMENT : P_OUT ; 

/EP1. M( 5) /MACRO. P( 7)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO. P(8)/ELEMENT : P_OUT ; 

/EP1. M(5)/MACRO. P(8)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(5)/MACRO/OE : P_OUT ; 

/EP1. M(5)/MACRO/OE : X( 1 TO 18) ; 

/EP1. M(6)/MACRO : A(1 TO 18) ; 

/EP1. M(6) /MACRO : EN ; 

/EP1. M( 6 ) /MACRO : EN_LOC ; 

/EP1. M(6)/MACRO : LOC(l TO 8) ; 

/EP1. M( 6 ) /MACRO : OR_OUT ; 

/EPl.M(6)/MACRO.P( 1)/ELEMENT : P_OUT ; 

/EP1. M( 6 )/MACRO. P(l) /ELEMENT : X( 1 TO 18) ; 

/EP1. M( 6) /MACRO. P( 2) /ELEMENT : P_OUT ; 

/EP1. M( 6) /MACRO. P( 2) /ELEMENT : X( 1 TO 18) ; 

/EP1. M(6)/MACRO. P(3)/ELEMENT : P_OUT ; 

/EP1. M(6)/MACRO. P(3)/ELEMENT : X( 1 TO 18) ; 

/EP1. M(6)/MACRO. P(4)/ELEMENT : P_OUT ; 

DEC-13-1988 14:26:12 VHDL Simulator 

SIGNAL NAME MAP 
KERNEL = «SHU»TEST_EP3 

/EP1. M(6)/MACRO. P(4)/ELEMENT : X( 1 TO 18) ; 

/EP1. M( 6) /MACRO. P( 5) /ELEMENT : P_OUT ; 

/EP1. M( 6) /MACRO. P( 5) /ELEMENT : X( 1 TO 18) ; 

/EP1. M( 6) /MACRO. P( 6) /ELEMENT : P_OUT ; 

/EP1. M(6)/MACRO. P( 6) /ELEMENT : X( 1 TO 18) ; 

/EP1. M( 6)/MACRO. P( 7 ) /ELEMENT : P_OUT ; 

/EP1. M( 6) /MACRO. P( 7) /ELEMENT : X( 1 TO 18) ; 

/EP1. M( 6) /MACRO. P( 8) /ELEMENT : P_OUT ; 

/EP1. M( 6)/MACRO. P ( 8 ) /ELEMENT : X( 1 TO 18) ; 

/EP1. M(6)/MACRO/OE : P_OUT ; 

/EP1. M(6)/MACRO/OE : X( 1 TO 18) ; 

/EP1. M(7)/MACRO : A( 1 TO 18) ; 

/EP1. M(7)/MACRO : EN ; 

/EP1. M( 7) /MACRO : EN_LOC ; 

/EP1. M( 7 ) /MACRO : LOC(l TO 8) ; 

/EP1. M( 7 ) /MACRO : OR_OUT ; 

/EPl.M(7)/MACRO. P( 1)/ELEMENT : P_OUT ; 

/EP1. M( 7 ) /MACRO. P( 1) /ELEMENT : X( 1 TO 18) ; 



i. 
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/EP1. M(7)/MACR0. P(2)/ELEMENT : 
/EP1. M(7)/MACR0. P(2)/ELEMENT : 
/EP1. M( 7) /MACRO. P( 3) /ELEMENT : 
/EP1. M(7)/MACRO. P(3)/ELEMENT : 
/EP1. M(7)/MACRO. P(4)/ELEMENT : 
/EP1. M( 7)/MACRO. P(4)/ELEMENT : 
/EP1. M( 7) /MACRO. P( 5) /ELEMENT : 
/EP1. M( 7)/MACRO. P(5)/ELEMENT : 
/EP1. M( 7)/MACRO. P(6)/ELEMENT : 
/EP1. M( 7) /MACRO. P( 6) /ELEMENT : 
/EP1. M( 7) /MACRO. P( 7) /ELEMENT : 
/EP1. M( 7) /MACRO. P( 7) /ELEMENT : 
/EP1. M(7)/MACRO. P(8)/ELEMENT : 
/EP1. M(7)/MACRO. P(8)/ELEMENT : 
/EP1. M( 7) /MACRO/OE : P_OUT ; 
/EP1. M( 7)/MACRO/OE : X( 1 TO 18) 
/EP1. M( 8) /MACRO : A( 1 TO 18) ; 
/EP1. M(8)/MACRO : EN ; 

/EP1. M( 8) /MACRO : EN_LOC ; 

/EP1. M( 8) /MACRO : LOC(l TO 8) ; 
/EP1. M( 8)/MACRO : OR_OUT ; 

/EP1. M( 8) /MACRO. P(l) /ELEMENT : 
/EP1. M( 8) /MACRO. P(l) /ELEMENT : 
/EP1. M(8)/MACR0. P(2)/ELEMENT : 
/EP1. M(8)/MACRO. P(2)/ELEMENT : 
/EP1. M( 8) /MACRO. P( 3) /ELEMENT : 
/EP1. M( 8) /MACRO. P( 3) /ELEMENT : 
/EP1. M(8)/MACRO. P(4)/ELEMENT : 
/EP1. M( 8) /MACRO. P( 4) /ELEMENT : 

, /EP1. M(8) /MACRO. P(5)/ELEMENT : 

;■ EP1. M( 8) /MACRO. P( 5) /ELEMENT : 
/EP1. M(8)/MACR0. P( 6) /ELEMENT : 
/EP1. M( 8) /MACRO. P( 6) /ELEMENT : 
/EP1. M( 8) /MACRO. P( 7) /ELEMENT : 
/EP1. M( 8) /MACRO. P( 7) /ELEMENT : 
/EP1. M(8)/MACRO. P(8)/ELEMENT : 
/EP1. M(8)/MACR0. P(8)/ELEMENT : 
/EP1. M( 8) /MACRO/OE : P_OUT ; 
DEC-13-1988 14:26:12 



p 


OUT ; 




X( 


1 


TO 


18) 


p 


OUT : 




X( 


1 


TO 


18) 


p 


OUT ; 




X( 


1 


TO 


18) 


p 


OUT : 




X( 


1 


TO 


18) 


p 


OUT : 




X( 


1 


TO 


18) 


p 


OUT ; 




X( 


1 


TO 


18) 


p 


OUT ; 




X( 


1 


TO 


18) 



P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 




P OUT ; 




X(1 TO 18) 
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/EP1. M(8)/MACR0/0E : X( 1 TO 18) ; 
/EP1/P : P_OUT ; 

/EP1/P : X(1 TO 18) ; 

/EP1/R : P_OUT ; 

/EP1/R : X(1 TO 18) ; 
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APPENDIX D. MACRO VAX/VMS SYSTEM COMMAND 



A. MACRO VAX/VMS SYSTEM COMMAND FOR EP310 MODEL 



! FILE NAME: Batch (for EP310 model) 

$set def f shu. vhdl. altera] 

$set verify 

$vls setlib shu 

$vhdl eprom_pack 

$mg eprom_pack 

$mg/body eprom_pack 

$set def [ shu. vhdl. altera. ep310] 

$set verify 
$vls setlib ep310 
$vhdl ep310_pack 
$mg ep310_pack 
$mg/body ep310_pack 
$vhdl d_reg 

$mg d_register(behavioral_2) 

$vhdl p_term 

$mg p_term(behavioral) 

$vhdl macrocell 

$mg macrocell(behavioral) 

$vhdl io_control 

$mg io_control(behavioral_l) 

$vhdl ep310 

$mg ep310(structural) 

$set def [ shu. vhdl. altera. ep310. test] 

$set verify 

$vls setlib shu 

$vhdl test_bench 

$vhdl test_ep310 

$mg/top test_bench( ep310) 

$build/replace/ker=test_ep3 test_bench( ep310) 
$sim test_ep3/param=20000000 ,4 
$rg test_ep3 test_ep310. rcl 
$exit 
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B. MACRO VAX/VMS SYSTEM COMMAND FOR EP1800 MODEL 



! FILE NAME: Batch (for EP1800 model) 

$set def [ shu. vhdl. altera] 

$set verify 

$vls setlib shu 

$vhdl eprom_pack 

$mg eprom_pack 

$mg/body eprom_pack 

$set def [ shu. vhdl. altera. epl800] 

$set verify 
$vls setlib epl800 
$vhdl epl800_pack 
$mg epl800_pack 
$mg/body epl800_pack 
$vhdl d_reg 

$mg d_register(behavioral) 

$vhdl p_term 

$mg p_term(behavioral) 

$vhdl io_control 

$mg io_control( behavioral) 

$vhdl local_m 

$mg local_macrocell( structural) 

$vhdl global_m 

$mg global_macrocell( structural) 

$vhdl quadrant 

$mg quadrant( structural) 

$vhdl epl800 

$mg epl800( structural) 

$set def [ shu. vhdl. altera. epl800. test] 

$set verify 

$vls setlib shu 

$vhdl test_bench 

$vhdl test_epl800 

$mg/top test_bench( ep!800) 

$build/replace/ker=test_count test_bench( epl800) 
$sim test_count/para=0 , 20/trace=select. signal 
$rg test_count test_epl800. rcl 
$exit 
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